## 공개키(PKI)가 왜 나왔냐??? 키교환과 전자서명!
관용적인 암호화 방식에 있어서 대표적으로 비밀키(대칭키)가 주를 잡고 있었다.
비밀키는 같은 키로써 암복호화를 수행하지만, 비밀키를 건내받는 부분에 있어서 위험했다.
암복호화 키가 갖고, 수행속도는 빠르나, 누구나 동일한 키를 이용해 복호화를 하기 때문에 누가 해독했는지는 알 수 없음. 부인방지등 인증기술에는 사용하기 어렵다.
공개키 대표적 알고리즘 RSA는 DES암호화 방식을 개선했고, 공개키 비밀키라는 키쌍이 생성되며,
공개키로 암호화하고, 비밀키로 복호화하는 방식이다.
공개키는 암호화만 할 수 있고, 배포되어도 상관없지만, 비밀키는 타인에게 절대 배포하지 않는다.
RSA암호화의 실제 원리를 아래와 같이 예를 들면
1. 서로 각자의 공개키쌍을 서로 주고 받는다. (암호를 만들 수 있는 공개키를...)
남친 : 여친의 공개키, 자신의 비밀키 소유
여친 : 남친의 공개키, 자신의 비밀키 소유
2. 남친은 여친에게 전달할 문서를 여친의 공개키로 암호화하여 여친에게 준다.
3. 여친은 남자에게 받은 암호문서를 자신의 비밀키로 복호화한다. - 인증
4. 여친은 공개키를 남친에게만 주었으므로 복호화에 성공하면 남친이 보낸 문서임이 확실하다.
5. 여친이 남친의 공개키로 받았다는 답신을 암호화해서 남친에게 준다.
6. 남친은 받은 암호문서를 자신의 비밀키로 복호화한다.
7. 복호화가 되었으면 여자친구가 문서를 제대로 받았다는 것이 확인 된다. - 부인방지.
공캐키는 비밀키 암호화방식처럼 암복호화하는 키가 같지 않고 암호화하는 키와 복호화하는 키가
서로 다르다. 이를 키쌍(Key Pair)이라고 하며,
하나는 자신이 보관하는 비밀키, 하나는 상대방에게 공개하는 공개키로 이루어져 있다.
개인키로 암호화한 평문은 대응되는 공개키로만 복호화가 가능하고,
반대로 공개키로 암호화한 평문은 대응되는 개인키로만 복호화할 수 있다.
이런 공개키 암호화는 키교환과 전자서명의 목적으로 사용된다.
비밀키 암호화를 하기 위해서는 안전한 키 교환이 필수이다. 하지만 보안이 정의되지 않은 경로를 비밀키를
전송하는 것은 매우 위험한 일이므로 어려운 일이다.
공개키는 공개되는 키이므로 안전하지 않은 경로라 하더라도 상관이 없다.
이러한 성질로 공개키 암호화는 비밀키를 교환하는 데 사용된다.
이렇게 서로의 공개키가 교환이 되고나면,,,
나는 상대방의 공개키로 메세지를 암호화 하여, 이 암호문을 상대방에게 전달
상대방은 전달받은 암호문을 자신(상대방)의 비밀키로 복호화하여 메세지를 얻는다.(인증)
이렇게 하여 서로 같은 비밀키를 공유할 수 있다.(메세지 = 비밀키)
비밀키를 공유하면, 이제 비밀키암호화도 가능하게 되는 것 이다.
그럼 애초부터 공개키암호화만 하면 되지 않느냐..? 표를 참고해서 장단점에 맞게
쓰자는데 왜 시대를 역행하려고 하는가 ㅋㅋㅋ
이렇게 공개키 암호화 / 개인키 복호화에 RSA 알고리즘이 사용된다.
이 상황에 전자서명이 이루어지는 절차를 보자.
<엘리스가 전자서명을 하고 밥이 검증을 한다.>
서명에 있어서, 메시지 압축함수라는 것은 Hash함수를 일컫는다.
Hash를 하는 이유는, 공개키는 암호화데이타의 길이와 속도에 제한이 있으므로,
원문을 Hash를 실시하여, 메시지를 압축시킨 후 실시한다.
1.1 엘리스가 메세지를 해쉬한다.
1.2 엘리스가 해쉬된 메세지를 자신의 개인키로 메세지를 암호화한다.
1.3 엘리스가 전자서명을 한다. ~ 전송
2.1 밥이 메세지(원문)를 해쉬한다. - (1)
2.2 밥이 전달받은 전자서명 메세지를 엘리스의 공개키로 복호화한다.(그림 잘못 된 듯?) -(2)
2.3 (1)과 (2)가 같다면 서명값 검증에 성공한 것이다.
1. PKI (public key infrastructure) ; 공개키 기반구조
PKI는 기본적으로 인터넷과 같이 안전이 보장되지 않은 공중망 사용자들이, 신뢰할 수 있는 기관에서 부여된 한 쌍의 공개키와 개인키를 사용함으로써, 안전하고 은밀하게 데이터나 자금을 교환할 수 있게 해준다. PKI는 한 개인이나 기관을 식별할 수 있는 디지털 인증서와, 인증서를 저장했다가 필요할 때 불러다 쓸 수 있는 디렉토리 서비스를 제공한다. 비록 PKI의 구성 요소들이 일반적으로 알려져 있지만, 공급자 별로 많은 수의 서로 다른 접근방식이나 서비스들이 생겨나고 있으며, 그동안에도 PKI를 위한 인터넷 표준은 계속하여 작업이 진행되었다. PKI는 인터넷 상에서 메시지 송신자를 인증하거나 메시지를 암호화하는데 있어 가장 보편적인 방법인 공개키 암호문을 사용한다. 전통적인 암호문은 대개 메시지의 암호화하고 해독하는데 사용되는 비밀키를 만들고, 또 공유하는 일들이 관여된다. 이러한 비밀키나 개인키 시스템은, 만약 그 키를 다른 사람들이 알게 되거나 도중에 가로채어질 경우, 메시지가 쉽게 해독될 수 있다는 치명적인 약점을 가지고 있다. 이러한 이유 때문에, 인터넷 상에서는 공개키 암호화와 PKI 방식이 선호되고 있는 것이다 (개인키 시스템은 때로 대칭 암호작성법, 그리고 공개키 시스템은 비대칭 암호작성법이라고도 불린다). |
메시지에 대한 보안 서비스를 제공하기 위해서 세가지 형태의 보안 메시지를 생성하고 처리한다.
PKCS7과 관련이 높다.
메시지 형태 | 보안 서비스 |
서명 메시지 (SignedData) - by 인증서, 개인키(복호화) | 인증, 무결성 |
비대칭키 암호 메시지 (EnvelopedData) | 기밀성 |
서명 및 비대칭키 암호 메시지 (SignedAndEnvelopedData) | 인증, 무결성, 기밀성 |
- 인증 : 통신의 주체가 적법한지를 확인할 수 있어야 한다.(전자서명)
- 무결성 : 정보의 위변조 여부를 확인할 수 있어야 한다.(해쉬) - RSA서명시에 무조건 해쉬가 들어감.
- 기밀성 : 정보의 수신자를 제외한 제3자가 정보를 볼 수 없어야 한다.(암호화)
- 부인방지 : 공개키는 상대에게만 배포했으므로복호화가 됬다는 것 자체가 ... (부인방지)
3. PKCS(Public-Key Cryptography System) ; 공개키 암호작성 시스템
RSA 에서 정한 PKCS 표준들은 여럿이 있지만, 일단 중요빈도의 개인적 판단으로.. 다음의 표준만...
- PKCS12 : 인증서, 개인키와 같은 중요한 개인 정보(PFX)를 이동하기 위한 위한 표준
- PKCS8 : 비밀번호 기반의 개인키 정보, 암호화 또는 복호화를 위한 표준
ex)인증서 + 개인키 -> PFX
암호화개인키 -> 복호화 by pkcs8
인증서+복호화개인키 -> PFX by pkcs12
ex)PFX -> 인증서 + 개인키
pfx -> 인증서 + 개인키 by pkcs12, password
4. X.509
X.509는 암호학에서 공개키 인증서와 인증알고리즘의 표준 가운데에서 공개 키 기반(PKI)의 ITU-T 표준이다. X.509 시스템에서 CA는 X.500 규약에 따라 서로 구별되는 공개키를 가진 인증서를 발행한다.
한 조직의 인증된 루트 인증서는 그 PKI 시스템을 사용하는 모든 직원들에 분배될 수 있다. 인터넷 익스플로러나 모질라, 오페라와 같은 브라우저는 SSL 인증서라 불리는 미리 설치된 루트 인증서가있다. 사용자가 이 루트 인증서를 제거하거나 사용중지할 수도 있기는 하지만, 거의 그러지는 않는다.
X.509는 또한 CRL (certificate revocation list : 인증서 해지 목록) 구현을 위한 표준도 포함한다. IETF에서 승인된 인증서 유효성 점검 방법은 OCSP(Online Certificate Status Protocol)이다.
CRL은 인증서 해지 목록에 대한 것으로, 인증서를 검증하기 위해 유효한지, 폐기된 것인지, 만료된 것인지 등을 확인하게 해주는 것 이다. CRL업데이트 자체가 짧은 기일로 빈번이 이루어진다.
OCSP (online certificate status protocol) ; 온라인 인증서 상태 프로토콜
OCSP는 서버와 기타 네트웍 자원의 보안을 유지하기 위해 사용되는 두 가지 방식 중 하나로서, 인증서 폐기 목록을 주기적으로 갱신해야만 하는 CRL의 단점을 보완하기 위한 프로토콜이다.
OCSP는 사용자가 서버에 접근을 시도하면 인중서 상태 정보를 실시간으로 요청하며, 인증서 상태를 관리하고 있는 서버는 유효성 여부에 관한 응답을 즉시 보내준다. 이 프로토콜은 서버와 클라이언트 측 응용프로그램 간의 통신 구문을 정의하고 있다.
X.509 인증서의 확장자는 다음과 같다:
- .CER - CER 암호화 된 인증서. 복수의 인증서도 가능.
- .DER - DER 암호화 된 인증서.
- .PEM - (Privacy Enhanced Mail) Base64로 암호화 된 인증서. "-----BEGIN CERTIFICATE-----"와 "-----END CERTIFICATE-----" 가운데에 들어간다.
- .P7B - .p7c 참조.
- .P7C - PKCS#7 서명 자료 구조(자료는 제외), 인증서이거나 CRL(복수도 가능).
- .PFX - .p12 참조.
- .P12 - PKCS#12, 공개 인증서와 암호로 보호되는 개인 키를 가질 수 있다(복수도 가능).
PKCS#7는 데이터를 서명하거나 암호화 할 때 쓰이는(enveloping) 표준이다. 서명된 데이터를 검증할 때는 인증서가 필요하기 때문에 서명 자료 구조에 인증서를 포함하기도 한다. .P7C 파일은 데이터가 아니라 서명 자료 구조일 뿐이다.
PKCS#12는 PFX(개인 정보 교환:Personal inFormation eXchange)이 발전된 형태이며, 하나의 파일에서 공개 / 개인 자료들을 교환할 때 쓰인다.
A .PEM 파일은 단수, 혹은 복수의 인증서와 개인 키를 가질 수 있으며 적절한 시작/종료 라인 사이에 위치한다(CERTIFICATE or RSA PRIVATE KEY).
(위키백과 : http://ko.wikipedia.org/wiki/X.509)
5. Algorithm - 대칭키, key? iv?
해쉬 및 PKCS#7로부터 서명데이타 생성(SignedData) : 서명시 Hash를 하게 된다. (결과 길이)
- MD5(16byte), SHA1(20byte), SHA256(32byte)
대칭키 알고리즘 : 3DES, Seed,ARIA
공개키 알고리즘 : RSA (SignedData, EnvelopedData 생성시)
3DES(TripleDES)는 DES를 3번연속시킨 DES를 보완한 알고리즘인데,
DES는 Key가 8byte인 반면에 3DES는 3번이므로 24byte가 필요하며,
DESede, eee.. 이런 것은
3DES 종류 중 하나로, DES를 3번할때, Encrypt, Decrypt의 철자를 따서
순서를 말하는 것이다.
Iv는 그럼 머냐?
mode에는 ECB, CBC... 가 있는데,
ECB Mode는 원본데이터를 8byte 단위로 쪼개어 암호화하며,
데이터의 일부라도 8byte로 쪼개어 해석이 가능합니다.
하지만 CBC모드는 8byte 단위로 암호화 한 데이터가 그 다음 8byte 암호화에도
적용이 되어 상호연관관계에 의한 원본 데이터의 중간 어느 부분만 따로
해석이 불가능한 구조입니다. 그러니까 총 16byte를 암호화 하는 것이죠.
그런데 첫번째 8byte는 같이 엮을 데이터가 없기 때문에, 초기벡터를 주고자
이 때 Iv 8byte가 들어가는 것입니다.
2011/11/28 - [I.T] - [용어] 3DES(TripleDES) Algorithm, ECB Mode, CBC Mode
6. 해쉬(Hash)
임이의 길이의 입력 데이터 스트링을 비교적 짧은 길이의 고정된 값(해쉬값 또는 해쉬코드)으로 출력하는 알고리즘
- 일방향성 : 주어진 해쉬코드로부터 동일한 해쉬코드를 생성하는 데이터스트링을 찾아내기 어렵다.
- 충돌지향성 : 주어진 데이터 스트링에 대하여 동일한 해쉬코드를 생성하는 데이터스트링을 찾아내기 어렵다.
- 메시지 압축, 전자서명(부인 방지)에 사용된다.
7. CA
국내 PKI는 최상위 인증기관이라하는 ROOT CA가 2곳이 있다.
행정안전부(GCMA)가 GPKI, 한국정보보호진흥원(KISA)가 NPKI 이다.
각 Root CA아래 여러 CA(인증기관)들이 있고, 그 CA에서 인증서들을 발급받아 사용하게 된다.
8. 암호체계 고도화
2012년부터 암호체계고도화시행으로 인해서 인증서와 키길이에 대해서 변동이 있다.
해쉬함수는 SHA1이 아닌 SHA256을 사용하여 20byte가 아닌 32byte를 만들게 되며,
RSA256을 사용하며, 공개키의 길이또한 1024bit에서 2048bit로 길어진다.
*. 키관리 서버-클라이언트의 Key Exchange 예
1. 클라이언트 : 서버에 요청
2. 서버 : 클라이언트에게 서버인증서(인증서가 공개키이다) 전달.
3. 클라이언트 : 메세지(큰의미없음, 키교환이기때문에)를 대칭키암호화, 대칭키 암호화하면서 발생된 세션키(비밀키)를 서버인증서로 비대칭키 암호화. 이 2가지를 전달
4. 서버 : 자신의 비밀키로 비대칭키 복호화하여 세션키(비밀키)를 추출, 추출된 세션키로 메세지를 복호화.
즉, 모두 비밀키(세션키)를 갖게 되어 대칭키암호화를 실시한다.
송신자는 수신자의 공개키를 받아, 암호화하여 전송(이때 발생된 비밀키를 저장)
수신자는 전달된 메세지를 복호화하면서, 비밀키를 추출하여 저장
- 이를 하이브리드 암호화 라고 한다던데? 맞나? 비대칭키 암호화 시스템으로 세션키를 공유하고,
이후에 대칭키 암호화 시스템을 이용. 꾸준히 비대칭키를 이용하지 않는 것은,
속도의 차이가 현저히 느리기 때문이다. 그리고 비대칭키에는 키길이 크기 때문이다.
'I.T' 카테고리의 다른 글
Process Explorer 종료 안 되는 프로세스(좀비프로세스 + 연결 프로세스 까지) 죽이기! Kill Process Tree! procexp.exe (3) | 2011.11.29 |
---|---|
[용어] 3DES(TripleDES) Algorithm, ECB Mode, CBC Mode (0) | 2011.11.28 |
USB속도측정 '아토' Atto_Disk_Benchmark 사용법, 다운로드 (0) | 2011.07.19 |
Windows XP에서 NTFS 포맷하기(ex. 16GB) (0) | 2011.06.12 |
지워지지 않는 Fasoo DRM 지워봅시다. 노 안전모드! (19) | 2011.04.25 |