공개키 암호

대칭키 암호의 단점

- 어떻게 키를 안전하게 공유할 것인가?

- 사용자의 수가 늘어날 수록 필요한 비밀키의 개수가 급격히 증가함 ( n(n-1)/2 개의 서로 다른 비밀키 필요 )

 

대칭 키 암호에서 네트워크 참여자에 따른 키 저장 소요 메모리의 예

- 128비트 키를 사용, 모든 장치는 상호 간 암호화에 사용할 128비트 대칭키를 공유

- 모든 장치는 각각의 대칭키에 대한 32비트 장치 ID를 저장

- 백엔드 시스템은 모든 대칭키와 해당 대칭키를 사용하는 개체의 32비트 장치 ID를 저장

Network size	대칭키의 전체 수	디바이스 당 키 저장 스토리지	백엔드에서 필요한 스토리지
2	1	20 Byte	24 Byte
5	10	80 Byte	240 Byte

디바이스 당 저장 스토리지 : (128비트 + 32비트) * (n-1)

백엔드 저장 스토리지 : (128비트 + 32비트 + 32비트) * 전체 키 수

 

거기에, 부인 방지를 제공하지 못함

 

대칭키 암호의 단점

1. 안전한 채널을 통해서 사용자가 서로 동일한 키를 사전에 공유해야 함

2. n명이 서로 비밀 통신을 하기 위해서 n(n-1)/2개의 키가 필요

3. 송신자나 수신자의 부인 방지를 제공하지 못함

---

공개키 시스템의 원리

- 개인 우편함 원리를 암호 알고리즘에 적용한 새로운 형태의 암호 기법

 

공개키 암호 개요

- 암호화용 키와 복호화용 키가 다르다

- 대칭키 암호기법에 비하여 속도가 느림 (약 1000배)

- 긴 문서의 암호보다 대칭키 암호 기법의 비밀키 암호화에 사용

 

도입

- RSA 공개키 암호 방식: Rivest, Shamir, Adleman, 1978년

 

Public Key (공개키) 누구나 이용할 수 있는 공개된 값	Private Key (개인키) 개인이 소장하고 있는 비밀 값
메시지 암호화에 사용 - 송신자는 수신자의 공개키를 이용하여 전달하고자 하는 메시지를 암호화	메시지 복호화에 사용 - 송신자가 보낸 암호문을 복호화할 때 사용하는 복호화키
서명 검증에 사용 - 수신자는 송신자의 공개키를 이용하여 수신한 메시지의 서명값을 검증	서명 생성에 사용 - 수신자에게 보내는 메시지의 서명값을 생성할 때 사용하는 서명 키

 

공개키 암호 기법, 키 관리

- 공개키는 공개하고 자신의 개인키만 관리

- n 사람이 암호화 통신 시 2*n개의 키가 필요

- 키분배 .. 디렉토리 서버에 각자의 공개키를 공개하여 필요할 때 상대방이 이용할 수 있도록 함

 

대칭키 암호 기법과 공개키 암호기법의 비교

	대칭키 암호 방식	공개키 암호 방식
게인이 보유하는 비밀키 개수	(n-1)개 (모든 상대방의 비밀키를 보유)	1개 (자신의 비밀키만 보유)
전체 비밀키 수	n(n-1)/2	2n
암호화 속도	고속	저속
대표 예	DES, AES, ARIA	RSA, ElGamal

---

전자서명(Digital signature)

	종이 서명	전자 서명
작성 형태	문서 내에 서명이 포함	문서와 서명이 분리되어 있음
검증 방법	기존 서명과 대조, 비교	별도의 검증 기술을 적용
서명과 문서의 관계	One-to-Many	One-to-One
서명 검증	기존 서명이 필요	공개 검증

메시지와 서명을 같이 보내서 검증

 

해시 함수를 이용한 전자 서명

- 공개키는 서명도 느려서 해시 함수로 짧은 해시값을 뽑고 나온 아웃풋을 개인키로 전자서명함

- 수신자는 해당 서명 복화한 값과 메시지 해싱하고 비교

 

보안 서비스

대칭키 & 공개키 암호

- 메시지 기밀성 제공

 

메시지 인증 코드(MAC)

- 메시지 무결성 제공

 

전자서명

- 메시지 출처 인증(Message Origin Authentication)

- 부인 방지(Non-repudiation)

- 메시지 무결성

---

전자서명 vs. MAC

	MAC	전자 서명
기반 시스템	대칭키 암호 시스템	공개키 암호 시스템
키 관리	n개의 키 관리	서명자의 (공개키, 개인키) 한 쌍만 관리
공개 검증 여부	MAC 생성에 사용된 키를 공유한 수신자만 검증 가능	누구나 검증 가능 (서명자의 공개키 이용)
부인 방지	X	O

---

공개키 기반 구조(PKI)와 인증서

공개키 기반 구조(PKI)의 필요성

- 전자 서명을 할 때 사용된 공개키가 정말로 송신자의 공개키인가?

 

인증서

- 신뢰할 수 있는 인증 기관(CA, Certificate Authority)을 이용하여 신뢰할 수 있는 안전한 공개키를 제공

공개키 기반 구조(Public Key Infrastructure)

- 공개키를 효과적으로 사용하여 안전한 암호화와 전자서명 기능 등을 제공하는 보안 환경

 

누군가는 검증을 해줘야 함

우리나라의 민간 최상위 인증 기관은 한국 인터넷 진흥원(KISA)

- 아래에 5개의 공인 인증 기관 : 한국정보인증, 코스콤, 금융결제원, 한국전자인증, 한국무역정보통신

 

인증서

- 사용자의 공개키에 사용자의 식별 정보를 추가하여 만든 일종의 전자 신분증

- 공인인증서 == 공인인증기관에서 발급받은 증서

- Alice의 공개키 + 인증 기관의 전자 서명

* 공개키에 대해서 최상위 기관이 자신의 개인키로 서명해둠, 그 값을 검증하면 됨

 

인증서의 폐기

- 유효기간 만료 시 인증서 폐기 필요

- 인증 기관에서 주기적으로 인증서 폐기 목록(CRL, Certification Revocation List)을 발급

- CRL에도 인증 기관이 전자서명을 하여 발급, 상대방의 인증서를 검증할 때 항상 최신 CRL을 확인

 

인증서 사용

Alice가 Bob의 공개키로 암호화하여 전송하려는 경우

- Bob의 인증서를 받고(공개키 + CA의 서명), 이를 인증 기관한테 확인 요청

- 확인 완료 시 암호문 생성

- Bob은 자신의 개인키로 복호화하면 됨

 

Alice의 전자 서명시

- Alice가 개인키로 서명 생성, 서명과 메시지를 같이 보냄

- Alice의 인증서를 인증 기관에서 인증받아 Alice의 공개키를 확정

- Bob은 Alice의 공개키로 검증

 

공인 인증서에 비밀번호는 왜 넣는가?

실제로는, 인증서 == 공개키가 포함된 인증서 + 개인키

개인키는 암호화되고, 개인키와 공개키가 같은 쌍인지 확인이 필요

패스워드를 대칭키로 하여 암호화된 개인키를 복호화

=> 개인키와 공개키가 같은 쌍인지 확인.. 개인키로 서명하고, 공개키랑 같이 은행에 서명된 거 보내서 검증

=> 같은 쌍이면 검증 완료. 이후 공개키 기반 시스템 운영 가능

 

1. 사용자가 이 공개키에 대응하는 개인키를 소유하고 있는가?

2. 해당 공개키는 실제로 그 자의 것인가?

 

공인인증서 폐지

2020.12~ 블록 체인, 생체 인증 등 다양하고 안전한 사설인증서비스에도 법적 효력 부여