암호키는 안전하고 생성되고 저장하고 분배하고 파기해야한다.
대칭키 암호화의 경우, 당사자들은 공통의 비밀 키를 공유해야 한다. 이 과정에서 키가 노출되어선 안된다.
공개키 암호화의 경우, 공개키는 모두에게 공개될 수 있지만 개인키는 반드시 비밀로 유지되어야 한다. 또, 공개키가 누구의 것인지 확실하게 알 수 있어야 한다.
전달 방법
1. 물리적으로 전달
2. 믿을만한 사용자가 분배
3. 사용중이던 키로 새로운 키를 분배
4. A가 신뢰할 수 있는 제3자 C와 안전한 통신 채널이 있다면, C가 A와 B 사이에서 키 중계
키 계층
세션키
- 한번 쓰고 버림 (temporary)
- 세션마다 새로 생성됨
마스터키
- 비교적 오랫동안 사용함.
- 키 분배 센터를 통해서 안전하게 전달
키 분배 센터 KDC는 당사자간 신뢰되고, KDC는 사용자의 마스터키를 알고 있다.
A가 B와 비밀 통신을 하려 할 때,
A는 KDC에게 IDa, IDb, N1을 전달한다. 여기서 N1은 nonce로, 메시지가 최신인지 확인하는 용도이다.
KDC는 A에게 Ks || IDa || IDb || N1 과 Ks 와 IDa를 Kb로 암호화한 정보를 Ka로 암호화하여 A에게 보내준다.
그리고 A는 Ks와 IDa를 Kb로 암호화한 정보를 B에게 보낸다.
B는 N2를 만들어서 세션키로 암호화해서 A에게 보내며 잘 받았다고 알려준다.
A는 B에게 받은 데이터를 세션키로 복호화하고, N2에 적절한 변화(N2 + 1 등)를 주어 전달한다.
여기서, 빨간 칸의 경우 Ks가 노출되면 A의 행세를 하며 B의 메시지를 몰래 가로챌 수도 있다.
Key Distribution Issues
대규모의 네트워크에서는 KDC가 계층으로 구성될 수 있고, 이들은 서로 신뢰해야 한다. 즉, 상위 KDC의 보안 문제가 하위 KDC에 영향을 끼칠 수 있다.
세션 키는 수명에 제한이 있어야 한다.
자동으로 키를 분배하는 시스템을 사용할 수도 있다.
중앙 집중식 KDC는 병목현상 및 여러 문제가 발생할 수 있어서 분산 키 분배가 필요하다.
키의 사용, 용도를 제어해야한다.
A와 B에게 Km이 있다고 하자.
A는 KDC없이 B에게 IDa와 N1을 보낸다.
B는 Ks, IDa, IDb, f(N1), N2를 Km으로 암호화해서 보낸다.
A는 B에게 f(N2)를 보냄으로 잘 받았음을 인증한다.
위 그림은 키의 용도를 컨트롤하기 위한 방법이다.
MasterKey에 ControlVector를 합친 값을 Key로 세션키를 암호화한다.
이로써 복호화할때 알맞은 컨트롤벡터를 사용해야 복호화할 수 있다.
공개키 시스템을 이용해서도 세션키를 분배할 수 있다.
N1 || IDa 를 B의 공개키로 암호화하여 B에게 전달한다.
B는 N1 || N2를 A의 공개키로 암호화하여 A에게 전달한다.
A는 N2를 B의 공개키로 암호화하여 회신한다.
이어서 A의 개인키로 세션키를 암호화한 값을 B의 공개키로 암호화하여 회신한다.
아래 두 과정은 E(PUb, N2 || E(PRa, Ks))로 압축할 수 있다.
Distribution of Public Keys
1. 공개 발표
만약 A와 B가 있을 때, M이 A의 공개키인척 하면서 자신의 공개키를 B에게 주면 메시지를 훔칠 수 있다.
2. 디렉토리 사용
이름-공개키 쌍을 가진 디렉토리를 사용. 아직도 위조와 조작될 가능성이 있음.
3. 공개 키 권한
디렉토리 방식의 관리를 더욱 엄격하게 통제. 공개키를 필요로할 때 실시간으로 디렉토리에 접근할 수 있어야 한다.
A가 Public-key Authority에게 T1이란 nonce를 달고 요청한다.
Public-key Authority는 자신의 개인키로 B의 공개키와 요청과 T1을 반환해준다.
A는 B에게 IDa와 N1을 PUb로 암호화하여 보낸다.
B는 A의 공개키를 알아내기 위해 A가 한 것을 반복한다.
4. Public-Key Certificates (공인인증서)
인증서는 특정 사용자의 신원과 그 사용자의 공개 키를 결합한다.
인증서에는 유효 기간이나 사용 권한 등의 추가적인 정보가 포함된다.
공개 키 인증서는 신뢰할 수 있는 공개키 권한이나 인증기관에 의해 서명된다.
누구나 인증 기관의 공개 키를 사용해서 인증서의 서명을 검증할 수 있다.
A가 인증기관에게 자신의 공개키를 보내면 인증기관은 A에게 T1, IDa, PUa를 인증기관의 개인키로 암호화한 Ca을 보낸다.
B 또한 같은 방법으로 Cb를 받는다.
A와 B는 Ca와 Cb로 서로를 증명한다.
X.509 Certificate
Version: 인증서의 버전
Serial Number: 고유한 일련번호
Signature algorithm: 인증서를 서명하는데 사용한 알고리즘
Issuer Name: 발급한 기관의 이름
Period of validity: 유효기간
Subject Name: 소유자
Subject's public key info: 알고리즘/파라미터/공개키
Issuer Unique Iden' : 발급자의 정보
Subject Unique Iden' : 소유자의 정보
Extensions: 추가 확장
그리고 위 모든 정보를 해시한 값을 인증기관의 개인키로 암호화한 값이 Signature에 들어간다.
맨 앞에 있는 version에 따라 담겨있는 내용이 그림과 같이 달라진다.
인증서의 확장 부분에는 키 및 정책 정보, 인증서 주체 및 발급자 속성, 인증서 경로 제약 등이 들어갈 수 있다.
인증서에 담긴 내용을 해시하여 인증기관의 개인키로 암호화한 값이 Signed Certificate이다.
이를 복호화한 결과와 인증서에 담긴 내용을 해시한 것을 비교하여 잘 생성됐는지 검증한다.
Certificate Revocation
인증서 철회는 인증서가 유효 기간 내에 있더라도 특정 사유로 인해 더 이상 유효하지 않게 되었을 때 그 인증서를 무효화하는 과정이다.
사용자의 개인키가 손상되거나 사용자가 더이상 CA에 의해 인증되지 않거나 CA 자체의 인증서가 손상된 경우가 이에 있다.
CA는 CRL로써 철회된 모든 인증서들의 목록을 담고 있다. 사용자는 CA의 CRL을 확인해서 인증서를 검증해야 한다.
이렇듯 인증서는 공개키 기반의 구조를 갖고 있다.
'학교강의필기장 > 암호학' 카테고리의 다른 글
15. 각종 암호학 알고리즘 정리 (1) | 2023.12.12 |
---|---|
14. User Authentication (0) | 2023.12.08 |
12. Digital Signatures (1) | 2023.12.08 |
11. Message Authentication (2) | 2023.12.07 |
10. Hash Functions (2) | 2023.12.06 |