블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

서버와 APNS(애플푸쉬서버)와의 보안 메커니즘 


애플 iOS 디바이스로 서버가 푸쉬를 보내고자 할때는, APNS 서비스를 거쳐야 한다.

푸쉬 메시지를 보내고자 하는 Provider 서버가 APNS로 푸쉬 요청을 보내면, APNS 서버가 디바이스로 푸쉬를 보내는 구조이다.

이때 APNS 서버와 Provider 서버를 어떻게 신뢰하는 지를 알아보자.

APNS 서버 입장에서는 Provider 서버가 해커가 아냐? 진짜 Provider 맞아? 하는 의문을 가질 수 있고, Provider 서버도 APNS 서버가 진짜 APNS 서버가 맞는지를 확인할 수 있어야 한다.

이를 양방향 SSL(TLS:Transport Level Security)를 이용해서 해결 한다.

먼저 SSL 메커니즘에 대해서 알아보자 SSL 을 비대칭 (PKI) 키 구조의 암호화를 이용하는데, Public Key Private Key 두개를 가지고 있다. Public Key로 암호화를 할 수 있지만, 반대로 암호를 푸는 복호화는 Private Key를 통해서만 가능하다.

그래서 서버가 SSL 연결을 보낼 때, Public Key를 클라이언트에 내려 보내면, 클라이언트는 그 Public Key를 사용해서 메시지를 암호화 해서 서버에 전송하고, Private Key를 가지고 있는 서버만이 그 메시지를 해석할 수 있는 구조이다.


Main In The Middle attack

그런데 이 과정에서 취약점이 발생하는데, 서버가 Public Key를 내려보낼 때 중간에 해커가 서버서부터 온 Public Key를 낚아채고, 자신이 새로운 Public Key A1 Private Key A2 페어를 만든 후, 새롭게 만든 Public Key A1을 클라이언트로 내려보낸다. 그러면 클라이언트는 이 Public Key A1을 가지고 암호화를 해서 중간에 해커에게 보내고, 해커는 이 메시지를 자신의 Private Key A2로 열어서 본후에, 다시 원래 서버가 준 Public Key로 메시지를 암호화 해서 서버에 보낸다.

이 때 클라이언트와 서버는 Public Key Private Key로 안전하게 통신하는 것 처럼 보이지만, 사실은 사실은 중간에 해커에 의해서 메시지가 도청되고 있는 상황이 된다. 이런 Attack 방식을 Man In The Middle attack (MITM)


Signing

이러한 Public Key가로채기를 막을려면 Public Key를 받는 클라이언트 쪽에서 이 Public Key APNS에서 온 것이 맞는지를 확인하면 되는데, 보통 이 Public Key는 인증서(Certificate)안에 넣어서 클라이언트에게로 배달된다. 이 때 메시지 변조를 막기 위해서 Certificate는 안에 들어 있는 메시지로 생성된 일종의 해쉬값과 같은 signature 값을 가지고 있어서, 만약에 내부 메시지가 변경이 되면 원래 signature와 비교하여 메시지가 변경되었는지를 확인할 수 있다.이를 생성하는 것을 싸이닝(Signing) 이라고 하는데, Signing Private 키로 생성되고, 이에 대한 비교는 Public Key를 통해서 할 수 있다. (Sign을 확인하기 위해서는 Sign에 사용된 Private Key에 대한 페어 Public Key를 가진 인증서를 가지고 있어야 한다. Public Key를 통해서 싸이닝을 확인할 수 있다.)




Channing

signature를 통해서 전달되는 메시지가 변조되는 것을 막을 수 는 있지만 위의 MITM attack 처럼 인증서 자체를 통째로 바꿔칠 수 있기 때문에, 이 인증서가 믿을만한 인증서인지를 확인해야 한다. 인증서에는 인증서를 발급한 기관 (CA : Certificate Authority)정보가 들어 있는데, “XXX에서 인증서를 발급함이라는 정보가 들어 있다.

그런데 문제는 이 인증서를 발급한 기관을 믿을 수 있냐는 거다. 구멍가게가 될 수 도 있고

은행과 같은 인증된 기관이 될 수 도 있다. 그래서 사용하는 기법에 인증서 Channing 기법인데, 인증서를 발급한 사람이 이 인증서를 신뢰된 기관에 가서 인증을 받은 후, 그 인증 정보를 인증서에 추가하는 방식이다.

아래 그림을 보자, 맨 아래의 Engineering CA는 자체 적으로 인증서를 발급하였다. 이 인증서를 USA CA certificate에 보내서 추가 인증을 받는다. 그런데, USA CA certificate 인증서는 이미 신뢰된 기관으로부터 인증을 받은 인증서이기 때문에, 이 신뢰된 기관의 인증 정보가 추가되게 된다. (신뢰된 인증 기관으로부터 인증서에 서명을 받으려면 회사 정보,신상 정보 등을 받은 후에 신원 확인 절차를 거쳐야만이 서명을 받을 수 있다.)



(출처 : https://developer.mozilla.org/en-US/docs/Introduction_to_Public-Key_Cryptography)

그래서 최종 인증서 모양은



이러한 형태가 되고, 클라이언트는 이 인증서 chain을 통해서 Root CA가 신뢰된 인증서인지를 확인하면 이 전체 인증서가 신뢰된 인증서임을 확인할 수 있다. (네트워크를 통해서 Root CA가 맞는지를 확인하게 되고, 만약에 Root CA라도 외부로 노출이 되었을 경우에 Revoked List라는 유출된 인증서 목록을 유지함으로써 인증서가 문제가 없는 인증서인지를 확인할 수 있다.)

이러한 절차를 거치면 MITM Attack을 통한 감청을 막을 수 있다.

다음 문제는 클라이언트 입장에서는 서버가 신뢰할 수 있는 서버인지를 알 수 있다. (Provider는 이 Root CA를 통해서 서버가 APNS 서버임을 알 수 있다.)


Mutual SSL

그러나 서버 입장에서는 클라이언트가 Provider서버가 맞는지? 를 확인할 필요가 있다. 이것이 인증 (authentication) 과정인데, TLS(SSL) 연결이 안전하게 설정된 후에, 사용자 ID,PASSWD를 넣어서 클라이언트(Provider)를 확인하는 방법도 있지만, 조금 더 확실한 방법으로, 클라이언트가 발급한 인증서를 사용하는 방식을 사용한다.

이 방식이 양방향 SSL 방식 (Mutual SSL) 인데, SSL 연결이 될 때 서버가 클라이언트에게 Public Key 를 내려 보내는 방식과 마찬가지로 클라이언트가 서버에게 Public Key를 전송하고 메시지를 클라이언트의 Private Key를 이용해서 암호화 해서 보내는 방법이다.

이 때 클라이언트에서 서버로 전송하는 Public Key는 인증서를 통해서 전달이 되게 되고, 인증서에는 인증서 발급 기관등의 정보가 들어가 있기 때문에, 이를 통해서 클라이언트를 인증을 할 수 있다.


APNS CSR

그래서 APNS의 경우에는 Service Provider Private/Public Key pair 를 생성한 후에, Public Key만을 담은 인증서를 생성하여, 웹사이트를 통해서 Service Provider 업체에 대한 정보와 함께, 싸인을 요청한다.

싸인을 진행할 때 애플은 인증서에 대한 고유 ID등을 통해서 이 인증서를 통한 호출이 어느 기관(업체)에서 들어오는지를 맵핑 해놓고, 향후 양방향 SSL 연결시에 이 정보를 가지고 클라이언트를 판독할 수 있다.

이를 기반으로 전체 서버간의 플로우를 보면

1.  ProviderPrivate Key를 생성한다

2.  Private Key를 기반으로 *.csr 파일(인증서 싸인 요청 파일)을 만든다. 이 파일에는 Public key가 들어 있는 인증서와 싸이닝을 요청하는 Provider의 업체 정보들이 들어가 있다.

3.  Provider는 애플 포탈에 들어가서 이 csr 파일을 업로드 한다.

4.  애플 포탈은 csr 파일을 기반으로 인증서(certificate)를 생성한후에, 애플의 인증서를 이용해서 싸인을 추가해서 Provider에게 돌려준다.

5.  Provider 4에서 받은 인증서(public key가 들어 있는)1에서 생성된 Private KeyProvider 서버내에 설치 한다.

6.  이때 1에서 생성한 Private Key,그리고 애플이 싸이닝하여 추가된 Public Key 가 들어 있는 인증서, 인증서 체인에 사용된 모든 인증서를 추가해서 한 파일(*.p12)에 넣는다.(*.p12 파일 포맷은 X.509를 지원하는 파일 포맷중에 유일하게 Private Key를 같이 넣을 수 있는 포맷이다.)




APNS Provider간의 Trust

다음 통신이 이루어지게 되면, 아래 그림과 같이

1.  Provider ServerTLS 연결을 요청한다.

2.  APNS 서버는 certificate(인증서) public key를 넣어서 내려 보낸다.

3.  Provider는 이 인증서의 Root CA를 확인하여, 이 인증서가 애플에서 온 정상적인 인증서임을 확인한다. (Provider가 상대편이 APNS임을 확인함)

4.  Provider는 앞의 CSR에 의해 생성된 인증서를 APNS에 보낸다.

5.  APNS 4에서 온 인증서에 애플의 인증서로 Sign 이 되어 있는 것을 확인하고, 클라이언트가 (Provider) 합법적인 클라이언트임을 확인하고,어떤 사용자인지를 판독한다. (APNS Provider가 누구인지를 확인하였다.)

6.  마지막으로 양 서버간의 신뢰돈 TLS(SSL)연결이 성립되었다.



 

'아키텍쳐  > Security & IDM' 카테고리의 다른 글

서버와 APNS(애플푸쉬서버)와의 보안 메커니즘  (3) 2014.10.07
OAuth 2.0 노트  (0) 2014.08.11
OAuth 2.0 based API 인증 메모  (0) 2014.06.05
Digital Signing의 개념  (0) 2014.05.21
Java keystore file  (0) 2013.09.27
SSL/TLS 관련 개념 링크  (1) 2013.09.24

Digital Signing의 개념

아키텍쳐 /Security & IDM | 2014.05.21 17:04 | Posted by 조대협


source : http://www.slideshare.net/simmikamra/digital-certificates?qid=2dec4a02-6d14-4694-9b6d-090a3da163b5&v=qf1&b=&from_search=1

'아키텍쳐  > Security & IDM' 카테고리의 다른 글

OAuth 2.0 노트  (0) 2014.08.11
OAuth 2.0 based API 인증 메모  (0) 2014.06.05
Digital Signing의 개념  (0) 2014.05.21
Java keystore file  (0) 2013.09.27
SSL/TLS 관련 개념 링크  (1) 2013.09.24
Security-애플리케이션 보안 1. 인증 방식 및 비밀번호 암호화  (0) 2013.06.09

Vert.x를 보면서, HTTP단이야 HTTPS로 Security 보장이 된다지만, TCP/IP Server는 어떻게 하는가가 의문이었는데, 이부분도 이미 다 준비되어 있다. Configuration 몇줄 만으로 TLS가 지원 된다.


http://vertx.io/core_manual_java.html#ssl-servers

NetServer server = vertx.createNetServer()
               .setSSL(true)
               .setKeyStorePath("/path/to/your/keystore/server-keystore.jks")
               .setKeyStorePassword("password");


아무리 봐도 잘만들었어...


REST API에 대한 보안

아키텍쳐 /대용량 아키텍쳐 | 2013.10.28 00:10 | Posted by 조대협

REST API 보안

조대협

REST API에 대한 보안에 대해서 알아보자. API 에 대한 보안은 인증, 메세지 암호화, 무결성 크게 3가지 관점에서 고민해볼 수 있다.


1)  인증

인증은, REST API를 호출한 사람(클라이언트)가 적절한 사용자 인가를 판단해주는 것이다. 아무나 API를 호출하는 것이 아니라 인증을 받은 사람많이 API를 호출해주게 하는 것인데, 쉽게 생각하면 사용자의 id,passwd로 서비스에 로그인을 하는 개념을 생각할 수 있다.

API Key 방식

API에 대한 인증 방법은 몇가지가 있는데, 그 중에서 가장 기초적인 방법은 API Key를 이용하는 방법이다. API Key, 특정 사용자만 알 수 있는 일종의 문자열이다. 현재 Amazon이 이 방식을 사용하고 있는데 API를 사용하고자 할때, 개발자는 API 제공사의 포탈 페이등에서, API Key를 발급 받고, API를 호출할때, API Key를 메세지 안에 넣어서 호출한다. 서버는 메세지 안에서 API Key를 읽어서, API가 누가 호출한 API인지를 인증하는 흐름이다.

OAuth 방식

가장 기초적이고 구현이 쉬운 방법이지만, 이 방법의 경우에는 표준이 없으며, API 서비스를 제공하는 쪽의 디자인 표준을 따르기 때문에, 근래에는 OAuth라는 형식의 인증 방식을 API 인증에 많이 사용한다. 구글이 이 방식을 사용하는데, OAuth Provider로 부터, 인증을 받으면, OAuth Token이라는 것이 생성된다. API를 호출하는 입장에서는 이 OAuth Token API 호출시 함께 넣어서 호출을 해서, 인증을 받는 방식이다.  OAuth의 경우 API Key 방식보다 조금 더 높은 보안 방식을 제공하고, 표준화가 되어 있기 때문에, API 서비스 제공자 입장에서는 서비스 확산을 위해서 권장되는 방법이다. OAuth의 경우에는 OAuth 인증 표준을 제공하는 인증 서버를 구축해야 하기 때문에, 구현 난이도가 API Key 방식에 비해서 높다.

Bi-diretional Certification

가장 높은 수준의 인증 방식을 제공할 수 있는 개념으로, 보통 HTTPS 통신을 사용할때, 서버에 인증서를 놓고, 단방향으로 SSL을 제공한다. 이 방식은 클라이언트에도 인증서를 놓고, 양방향으로 SSL을 제공하면서, API 호출에 대한 인증을 클라이언트의 인증서를 통해서 하는 방식이다. 가장 구현 방법이 복잡한 방식이기는 하지만, 공인 기관에서 발행된 인증서를 사용한다면 API 를 호출하는 쪽의 신원을 확실하게 할 수 있고, 메세지 까지 암호화 되기 때문에, 가장 높은 수준의 인증을 제공한다. 이런 인증 방식은 일반적인 서비스에서는 사용되지 않으며, 몇몇 높은 인증 수준을 제공하는 서비스나 특정 서버간의 통신을 위해서 사용 하는 것이 좋다.


2)  메세지 암호화

API 내용안에 다른 사람이 봐서는 안될 내용이 있다면 API 메세지를 암호화 해야 한다. 메세지를 암호화 하는 방법은 몇가지 접근 방법이 있는데, 그중에서 가장 손쉬운 방법이 HTTPS를 사용하는 방식이다. 이 방식의 경우에는 서버 설정만으로도 가능하고, 가장 널리 쓰이는 방식이기 때문에 신뢰할만하다.

그런데, HTTPS는 인증서를 이용해서, 초기 통신시에 SSL handshake를 통해서 Secure Connection을 제공하는 방식인데, HTTPS Client Server 사이에서 인증서를 바꿔치면, 중간에 이 인증서를 바꿔친 사람은 메세지를 볼 수 있다. 이를 Man in middle attack이라고 하는데, Server A Client B에게 인증서를 내려줄때, 중간에 Hacker C Server A의 인증서를 자신의 인증서로 바꿔서 Client B에게 전달한다. Client B Hacker C의 인증서로 메세지를 암호화해서 보내면, Hacker C가 중간에 메세지를 자신의 인증서를 이용해서 복호화해서 본후에, Server A가 보낸 원래 인증서로 다시 암호화 해서, 보내면, Server A는 문제가 없다고 판단한다. 실제로 중국 정부의 경우, 중국의 외부에서 들어오는 Traffic을 이러한 방법으로, 인증서를 바꿔쳐서 메세지를 복호화해서 필터링한다고 한다.

이런문제를 해결 하기 위해서는 Server A 에서 발급하는 인증서가 공인된 인증 기관의 인증서임을 확실하게 해주면 된다. 이렇게 인증서를 공인해주는 기관을 CA라고 하는데 Verisign 등이 대표적인 기관이다. 이렇게 공인된 인증서인지는 Client B가 인증서를 받아보고, 해당 인증서가 공인된 기관에서 발급된 인증서인지를 확인하면 된다. (클라이언트 쪽에, 인증서가 공인된 인증서인지를 확인하는 로직을 넣으면 Man in middle attack을 방지할 수 있다.)

데이타 레벨의 암호화

다음으로는 간단하게 암호화가 필요한 특정 필드만 애플리케이션단에서 암호화 해서 보내는 방법이 있다.



http://www.javamex.com/tutorials/cryptography/ciphers.shtml 를 참고하면, 대칭키 기반의 암호화 알고리즘 속도를 비교해놓은 것이 있다. 일반적으로 AES256을 사용하면 빠른 암호화 속도와 높은 보안성을 보장 받을 수 있다. (위, 대칭키 기반의 암호화 알고리즘 속도 비교)


3)  무결성 보장

무결성이란, 서버 입장에서 API 호출을 받았을때, 이 호출이 신뢰할 수 있는 호출인지, 아닌지를 구별하는 방법이다. Hacker가 중간에서 메세지를 가로챈후에, 내용을 변조해서 Server에 보냈을때, 내용이 변조되었는지 여부를 판단하는 방법인데, 일반적으로 HMAC을 이용한 방식이 널리 사용된다. 어떤 원리로 작동하는지 살펴보도록 하자.

먼저 전제는 Rest API를 호출하는 클라이언트와, 서버간에는 대칭키 기반의 암호화 키 “Key”를 가지고 있다고 전제하자. Key는 앞에서 설명한 API Key가 될 수 도 있고, OAuth 토큰이 될 수 도 있고, 또는 사용자가 임의로 정한 키가 될 수 도 있다.



(1) 먼저 클라이언트는 호출하고자 하는 REST API URL을 앞에서 정의한 Key를 이용해서 HMAC 알고리즘을 사용하여 Hash 값을 추출한다.

* 중요 : 여기서는 편의상 URL을 가지고 HMAC 해쉬를 생성하였는데, 전체 메세지에 대한 무결성을 보장하려면 URL이 아니라 메세지 전문 자체에 대해서 Hash를 추출해야 한다.

(2) 그리고 API를 호출할때, 메세지 (또는 URL)에 이 추출한 HMAC을 포함해서 호출한다.

(3) 서버는 호출된 URL을 보고 HMAC을 제외한 나머지 URL을 미리 정의된 Key를 이용해서, HMAC 알고리즘으로 Hash 값을 추출한다.

(4) 서버는 (3)에서 생성된 HMAC값과, API 호출시 같이 넘어온 HMAC 값을 비교해서, 값이 같으면 이 호출을 유효한 호출이라고 판단한다.

만약에 해커가 메세지를 중간에서 가로채서 변조하였을 경우, 서버에서 Hash를 생성하면 변조된 메세지에 대한 Hash가 생성되기 때문에 클라이언트에서 변조전에 보낸 Hash 값과 다르게 된다. 이를 통해서 메세지가 변조되었는지 여부를 판단할 수 있다.

Time stamp를 이용한 replay attack의 방지

그런데, 위의 알고리즘 상의 문제는, 만약에 메세지를 변경하지 않고, Hacker가 동일한 요청을 계속 보낸다면? 메세지를 변조하지 않았기 때문에 서버는 이를 유효한 호출로 인식할 수 있다. 이를 replay attack이라고 하는데 이를 방지하기 위해서는 time stamp를 사용하는 방법이 있다.

HMAC을 생성할때, 메세지를 이용해서만 Hash 값 생성하는 것이 아니라, timestamp를 포함해서 메세지를 생성하는 것이다.

HMAC (Key, (메세지 데이타+timestamp) )

그리고, API를 호출할때, timestamp 값을 같이 실어서 보낸다.

http://service.myapi.com/restapiservice?xxxxx&hmac={hashvalue}&timestamp={호출시간}

이렇게 하면 서버는 이 메세지가 호출된 시간을 알 수 있게 되고, 호출된 시간 +- 10(아니면 개발자가 정한 시간 폭) 만큼의 호출만 정상적인 호출로 인식하고 시간이 지난 호출의 메세지는 비 정상적인 호출로 무시해버리면 된다.

* 참고 : Hacker timestamp URL등을 통해서 볼 수 있다고 하더라도, Key값을 모르기 때문에, timestamp 를 변조할 수 없다. timestamp를 변조할 경우에는 원본 Hash가 원본 timestamp로 생성되었기 때문에, timestamp가 변조된 경우 hash 값이 맞지 않게 된다.

HMAC을 구현하는 해쉬 알고리즘은 MD5,SHA1등이 있는데, 보통 SHA-1 256bit 알고리즘을 널리 사용한다.

HMAC 기반의 REST Hash 구현 방법은

http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/

에 설명이 잘나와 있으니 참고하기 바란다.

또한 HMAC 알고리즘 구현은 위키 http://en.wikipedia.org/wiki/HMAC 를 보면 각 프로그래밍 언어별로 예제 링크가 나와 있으므로 참고하기 바란다.

지금까지 간단하게 나마 REST API 보안 방식에 대해서 알아보았다. 보통 REST API를 디자인하는데, 가장 신경 안쓰는 부분 중의 하나가 API 에 대한 보안이다. 대신 한번 뚤리기 시작하면 걷잡을 수 없이 문제를 만드는 부분이 또 보안이다. API 디자인시에는 반드시 보안에 대한 부분을 고려하고, 위의 3가지 관점에 따라서 API 보안을 반영하기 바란다.


글이 예전 내용이라서 새 글이 업데이트 되었씁니다.

REST API 이해와 설계 - #1 개념 잡기 http://bcho.tistory.com/953

REST API 이해와 설계 - #2 디자인 가이드  http://bcho.tistory.com/954

REST API 이해와 설계 - #3 보안 가이드  http://bcho.tistory.com/955



Java keystore file

아키텍쳐 /Security & IDM | 2013.09.27 00:43 | Posted by 조대협

Java KeyStore file에 저장되는 것들


http://docstore.mik.ua/orelly/java-ent/security/ch11_02.htm


Now that we understand the pieces that make up a key management system, we can look at the topic of key management itself. From an administrative perspective, the primary tool that provides key management for Java 1.2 is the keytool utility. Keytool operates upon a file (or other storage system) containing a set of private keys and certificates for those keys. The keytool file contains a set of entries; each entry may have the following attributes:

  • An alias. This is a name you can use to reference the entity in the database. For example, an alias for my entry might be sdo, or ScottOaks.

  • One or more certificates that vouch for the identity of the entry. These certificates also provide the public key for the entry.

  • Optionally, a private key. If present, the private key can be protected by a password.


SSL/TLS 관련 개념 링크

아키텍쳐 /Security & IDM | 2013.09.24 00:36 | Posted by 조대협

http://www.javaworld.com/javaworld/jw-01-2001/jw-0112-howto.html

http://www.javaworld.com/jw-02-2001/jw-0216-howto.html

http://juntheater.tistory.com/entry/keytool%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%9C-%ED%82%A4-%EC%83%9D%EC%84%B1

http://juntheater.tistory.com/entry/Java-SSL-%EA%B5%AC%ED%98%84


weblogic SSL Client sample

http://docs.oracle.com/cd/E11035_01/wls100/security/SSL_client.html

http://blog.palominolabs.com/2011/10/18/java-2-way-tlsssl-client-certificates-and-pkcs12-vs-jks-keystores/


PKI 관련 파일 명에 대한 개념 링크

http://serverfault.com/questions/9708/what-is-a-pem-file-and-how-does-it-differ-from-other-openssl-generated-key-file



Tomcat 2 way SSL (mutual SSL)

http://blog1.vorburger.ch/2006/08/setting-up-two-way-mutual-ssl-with.html



Self study memo

Public Key 기반의 암호화

암호화와 복호화키를 다른 키를 사용.

Private Key로 암호화 하고 Public Key 로 복호화를 함. Public Key는 공개되어도 상관 없음.

가장 널리 사용되는 Public Key 기반의 암호화 알고리즘으로는 RSA가 있음

 

인증서의 필요성

그러나 문제는 PKI 를 사용할 경우, 해커가 main in middle attack으로 pubic key를 가로챌 수 있다. 이를 방지하기 위해서, 3자의 공인된 인증 기관 (CA) public key를 등록하고, public key가 들어 있는 인증서(certification)을 발급 받아서 사용한다.

 

인증서 표준중, 많이 사용되는 인증서가 X.509 인증서 임


 

그외에 PGP(Pretty Good Privacy) Ceriticates SDSI (Simple Distributed Security Infrastructure)등이 있음.

 

인증서 Chain

상위 인증서가 하위 인증서에 대한 Public Key를 가지고 있음.

상위 인증서가

 

 

인증서 파일 포맷

PKCS

- X.509와 같은 인증서를 저장하기 위한 포맷 (PKCS12 is a password-protected format that can contain multiple certificates and keys)

CF. JKS

http://blog.palominolabs.com/2011/10/18/java-2-way-tlsssl-client-certificates-and-pkcs12-vs-jks-keystores/

 

 

인증서 파일 포맷은 크게

·         PEM Governed by RFCs, it's used preferentially by open-source software. It can have a variety of extensions (.pem, .key, .cer, .cert, more)

·         PKCS12 A private standard that provides enhanced security versus the plain-text PEM format. It's used preferentially by Windows systems, and can be freely converted to PEM format through use of openssl.

·         DER The parent format of PEM. It's useful to think of it as a binary version of the base64-encoded PEM file. Not routinely used by anything in common usage. --> 확장자가 *.CER 경우, DER 인코딩된 X.509 바이너리이거나, Base 64 인코딩된 X.509 인증서임

 

3가지가 주류로 나뉘어짐

세부적으로 보면

·         .csr This is a Certificate Signing Request. Some applications can generate these for submission to certificate-authorities. It includes some/all of the key details of the requested certificate such as subject, organization, state, whatnot, as well as the public key of the certificate to get signed. These get signed by the CA and a certificate is returned. The returned certificate is the public certificate, which itself can be in a couple of formats.

·         .pem Defined in RFC's 1421 through 1424, this is a container format that may include just the public certificate (such as with Apache installs, and CA certificate files /etc/ssl/certs), or may include an entire certificate chain including public key, private key, and root certificates. The name is from Privacy Enhanced Email, a failed method for secure email but the container format it used lives on.

·         .key This is a PEM formatted file containing just the private-key of a specific certificate. In Apache installs, this frequently resides in /etc/ssl/private. The rights on this directory and the certificates is very important, and some programs will refuse to load these certificates if they are set wrong.

·         .pkcs12 .pfx .p12 Originally defined by RSA in the Public-Key Cryptography Standards, the "12" variant was enhanced by Microsoft. This is a passworded container format that contains both public and private certificate pairs. Unlike .pem files, this container is fully encrypted. Every time I get one I have to google to remember the openssl-fu required to break it into .key and .pem files.

A few other formats that show up from time to time:

·         .der A way to encode ASN.1 syntax, a .pem file is just a Base64 encoded .der file. OpenSSL can convert these to .pem. Windows sees these as Certificate files. I've only ever run into them in the wild with Novell's eDirectory certificate authority.

·         .cert .cer A .pem formatted file with a different extension, one that is recognized by Windows Explorer as a certificate, which .pem is not.

·         .crl A certificate revocation list. Certificate Authorities produce these as a way to de-authorize certificates before expiration.

 

 

주의!! - 전자 서명과 인증서는 개념이 다름

전자 서명 (Digital Signature) Private signature를 생성한 후에, public key를 이용하여 descrypt 하여, 문서의 유효성을 판단.

이때, public key에 대한 변조를 막기 위해서 인증서(Certification) 를 통해서 public key를 전달함

 

http://blog.naver.com/jasonalive?Redirect=Log&logNo=80008939065


양방향 SSL 을 E2E로 구현하는 것에 목표를 두자.


SSL 과정

분류없음 | 2007.10.19 10:49 | Posted by 조대협

1.       클라이언트가 서버에 접속하면 서버인증서(서버의 공개키를 인증기관이 전자서명으로 인증한 것) 를 전송받습니다. (이때, 클라이언트 인증을 필요로 할 경우 클라이언트의 인증서를 전송하게 됩니다.)

2.       클라이언트는 받은 서버 인증서를 분석하여 신뢰할 수 있는 인증서인지를 검토한 후, 서버의 공개키를 추출합니다.

3.       클라이언트가 세션키로 사용할 임의의 메세지를 서버의 공개키로 암호화하여 서버에 전송합니다.

4.       서버에서는 자신의 비밀키로 세션키를 복호화하여 그 키를 사용하여 대칭키 암호방식으로 메시지를 암호화하여 클라이언트와 통신하게 되며 이것은 "https"라는 별도의 프로토콜을 사용하게 됩니다.

즉 공개키를 서버가 클라이언트로 내려보내면 클라이언트에서 세션키를 암호화해서 서버에 보내서 세션을 만든다.
--> one way handshake

인터넷을 검색해보면 http와 https의 성능 차이는 대략 20~40%정도가 나게 된다.