PKI는 클라이언트들에게 보내지는 공개키와 서버에 지역적으로 존재하는 비밀키로 구성되는 비대칭 키 시스템(asymmetric key system)으로 클라이언트와 서버 모두 암호화/복호화에 동일한 키를 사용하는 대칭 키 시스템(symmetric key system)과는 다르다.
SSL은 신용카드 정보, 의료 기록, 법률 문서와 전자 상거래 애플리케이션과 같은 가장 기밀을 다루는 트랜잭션(transaction)들의 전송에 이용되는 것을 허용할 수 있도록 하는 요건을 실현하기 위한 것이다. 각각의 애플리케이션은 처리될 트랜잭션의 중요도와 가치에 따라 다음 기준중 모두 또는 일부를 이용하려고 할 것이다.
가령 A로부터 B로의 전송을 목적으로 메세지가 암호화되었다고 가정하자. 메세지를 암호화하기 위해 A가 B의 공개키를 사용한다면 B는 자신의 비밀키를 이용하여 이 메세지를 복호화해서 해독할 수 있는 유일한 사람일 것이다. 그러나 A가 자신이 주장하는 누구라는 것을 확신할 수는 없다.
A가 자신이 주장하는 누구라는 것을 확신하기 위해 보증된 신뢰성을 원하는데 이는 약간은 더욱 복잡한 코딩 프로세스를 필요로 한다. 우선 B로 송신되는 A의 메세지는 A의 비밀키로 암호화된 후 B의 공개키로 암호화된다. B는 이제 우선 자신의 비밀키로 메세지를 복호화한 후 A의 공개키로 복호화해야 한다. 그래서 B는 어느 누구도 A의 비밀키로 암호화된 메세지를 생성할 수 없기 때문에 A가 자신이 주장하는 누구라는 것을 확신할 수 있다. SSL은 인증서를 사용하여 이를 달성하는데(PKI) 인증서는 인증서 발급기관(Certificate Authority, CA)과 같은 중립적인 제 삼자에 의해 발급되며 인증된 기관의 공개키외에 디지털 서명(Digital Signature)과/또는 time stamp를 포함한다. 자필 서명(Self-signed) 인증서는 SSL 도구를 사용하여 어느 누구라도 생성할 수 있지만 이는 공통적으로 존중되는 삼자에 의해 수행되는 인가로서의 영향력은 부족하다.
SSL에서 자료 무결성은 필요한 해쉬 테이블 함수를 갖는 MAC(Message Authentication Code)를 이용하여 보장된다. 메세지 생성후 해쉬 함수를 이용하여 MAC이 얻어지며 이것이 메세지에 첨가된다. 메세지가 수신된 후 그 유효성은 수신 메세지로부터 계산된 새로운 MAC와 메세지에 덧붙여진 MAC와 비교하여 검사된다. 이러한 방법을 통해 제 삼자에 의해 메세지가 변경되었는지의 여부를 즉각적으로 알 수 있다.
부인 방지는 온라인 트랜잭션 중에 송수신자 서로를 보호하는데 특정 정보의 송신 사실을 부정하지 못하게 한다. 또한 트랜잭션이 이루어진 후 이의 변경을 허용하지 않으며 디지털 부인 방지는 일반적인 의미로 계약 체결과 동일하다.
SSL 프로토콜은 SSL 레코드 프로토콜과 SSL 핸드쉐이크 프로토콜 두개의 하위 프로토콜을 포함한다. SSL 레코트 프로토콜은 데이터를 전송하는데 사용되는 포맷을 정의하며 SSL 핸드쉐이크 프로토콜은 SSL이 동작하는 서버와 클라이언트가 처음 SSL 연결을 맺을때 이들 사이에 일련의 메세지들을 교환하기 위해 SSL 레코드 프로토콜을 사용하는 것을 포함한다. 메세지 교환은 다음 기능들을 수월하게 하기 위해 설계되어 있다:
클라이언트에 서버를 인증한다. 서버 인증이 손상되지 않았고 신뢰 사슬(chain of trust)이 확립되었음을 보증하기 위해 서버 인증서는 CA에 의해 서명된다.
클라이언트와 서버 둘 모두가 지원하는 암호화 알고리듬 또는 암호(cipher) 선택을 허용한다.
임의로 서버에 클라이언트를 인증한다.
공유 비밀을 생성하기 위해 공개키 암호화 기법을 사용한다.
암호화된 SSL 연결을 확립한다.
SSL 핸드쉐이크 프로토콜
핸드쉐이크 프로토콜은 클라이언트와 서버의 상태를 통합하기 위해 사용되는데, 핸드쉐이크 중 다음 이벤트가 발생한다:
클라이언트와 서버 사이에 인증서가 교환된다(비대칭 키들). 서버가 클라이언트에 자신의 공개키를 보내는데 서버가 인증서를 통해 클라이언트 인증을 검증하도록 설정되어 있다면 클라이언트는 서버에 자신의 공개키를 보낸다. 인증서의 유효 날짜가 검증되며 신뢰받는 CA의 디지털 서명인지 검사되는데 유효 날짜와/또는 디지털 서명이 옳지 않다면 브라우저가 사용자에게 경고 메세지를 나타낼 것이다. 그리고 나서 인증서 보유자임을 확신하기 위해 사용자에게 옵션을 준다.
곧이어 클라이언트가 랜덤키(대칭키)를 생성하는데 랜덤키는 암호화와 MAC 계산을 위해 사용될 것이다. 그것들은 서버의 공개키를 사용하여 암호화되어 서버에 보내지는데 단지 서버만이 새로운 랜텀키를 복호화할 수 있다. 새로운 대칭키는 클라이언트와 서버사이에 보내지는 데이터를 암호화하는데 사용된다.
Note: 서버-브라우저 인증 후의 대칭키 사용으로 인해 효율 성능은 대단히 향상된다.
데이터 무결성을 위해 메시지 암호화 알고리듬과 해쉬 함수를 협의해서 결정한다. 이 협의(negotiation) 프로세스가 수행되어 클라이언트는 지원되는 알고리듬 목록을 서버에 건네주며 다음에 양쪽 모두에 이용할 수 있는 가장 강력한 암호를 선택한다. 선택된 암호화 알고리듬과 해쉬 함수 식별자는 레코드 프로토콜이 사용하는 현재 상태의 암호 스펙 필드에 저장된다.
프로토콜 버전, 세션 ID, Cipher Suite, 압축 방법과 두개의 임의 값인 ClientHello.random과 ServerHello.random 들과 같은 필드들은 핸드쉐이킹 동안에 설정된다.
Note: 각각의 SSL 연결을 위해 IP 주소가 필요한데 가상 호스트 이름이 애플리케이션 계층에서 분석된다. SSL이 애플리케이션 계층 아래에 존재함을 기억해라.
세션 키 (대칭 코드)
40 비트, 원래 export를 위해서만 사용
56 비트, DES 에서 사용
64 비트, CAST 에서 사용, 56 비트보다 256배 강력
80 비트, CAST에서 사용, 현재 기술로 해독할 수 없으며 56 비트보다 160만배 강력
128 비트, CAST 또는 RC2 에서 사용, 현재 및 가까운 미래에 완전한 키 검색이 불가능
공개/개인 키 쌍(비대칭 코드)
512 비트
768 비트
1024 비트
2048 비트
클라이언트와 서버는 각자 공개키와 비밀키를 갖는다 (클라이언트가 인증서를 갖고 있지 않고 서버가 인증서를 요청하지 않는다면 클라이언트의 브라우저가 SSL 세션을 위해 임의로 한쌍의 키를 생성한다).
송신자는 메세지를 암호화하기 위해 자신의 비밀키를 사용하는데 이것이 메세지의 출처를 인증한다. 결과적으로 생긴 암호문은 수신자의 공개키를 이용해 한 번 더 암호화되는데 단지 수신자만이 자신의 비밀키를 사용하여 메세지의 최초 복호화를 할 수 있기때문에 기밀성을 제공한다. 수신자는 암호화된 메세지를 더욱 복호화하기 위해 송신자의 공개키를 사용한다. 송신자만이 그 비밀키를 액세스하기 때문에 수신자는 암호화된 메세지가 송신자가 보냈다는 것을 확신한다.
메세지 다이제스트(digest)는 쌍방 또는 제 삼자가 어떤 방식으로든 메세지에 손을 대거나 변경하지 않았다는 것을 보증하기 위해 사용된다. 메세지 다이제스트는 메세지에 해쉬 함수(지문로 알려진 비밀키의 일부)를 적용함으로써 얻어지며 다이제스트(이제 서명으로 알려진)가 메세지에 첨부 또는 첨가된다. 서명의 길이는 일정(파일 크기에 무관하게)하며 비밀키가 함유하는 메세지 다이제스트의 유형에 의존한다(md5-128비트, sha1- 160 비트 등등). 메세지 중 단 한개의 비트라도 변경된다면 서명의 길이는 변경될 것이고 결국 메세지가 변경되었음을 입증한다.
디지털 인증서는 인터넷상에서 참여자(entity)를 신뢰할 수 있게 하는데 이는 중립적인 제 삼의 CA에 의해 입증된 사용자의 credential 을 포함한다.
데이터를 해독할 수 없는 형태로 암호화하기 위해 수학적 알고리듬과 값(키)이 사용되며 두번째 키가 보충(complementary) 알고리듬과 그 관련 값을 이용하여 데이터를 복호화하기 위해 사용된다. 이 두키는 관련된 값을 포함해야 하는데 키쌍(key pair)으로 알려져 있다.
Note: ITU-T 권고 X.509 [CCI88c]는 X.509 인증서 구문뿐만 아니라 X.500� 디렉토리 대한 인증 서비스를 지정한다. 인증서는 사용자(subject) 이름과 공개키간의 바인딩을 인증하기 위해 발급자에 의해 서명된다. SSLv3은 1994년에 채택되었는데 버전 2와 3의 주요 차이점은 확장(extension) 필드가 추가되었다는 것이다. 이 필드는 키와 이름 바인딩외에 부수적인 정보를 전달할 수 있기 때문에 더욱 융통성을 준다. 표준 확장은 사용자와 발급자 속성, 인가 정책 정보와 키 사용 제한을 포함한다.
X.509 인증서는 다음 필드로 구성된다:
버전
시리얼 넘버
서명 알고리듬 ID
발급자 이름
유효 기간
사용자(subject) 이름
사용자 공개키 정보
발급자 고유 식별자 (버전 2와 3에 해당)
사용자 고유 식별자 (버전 2와 3에 해당)
확장(extension, 버전 3에 해당)
위 필드에 대한 서명
비밀키는 디지털 인증서내에 덧붙여지지 않으며 어떤 서버 정보도 포함하지 않는다. 비밀키는 암호화 정보와 지문을 포함하는데 시스템내에 지역적으로 생성되며 안전한 환경내에 유지되어야 한다. 비밀키가 손상된다면 범죄자가 반드시 보안 시스템에 대한 코드를 갖는다. 클라이언트와 서버사이의 전송이 도청 및 복호화될 수 있다. 이러한 유형의 침입 가능성때문에 삼중 DES 기법을 이용하여 암호화되는 비밀키 생성이 추천되는데 파일은 정확한 pass phrase 없이는 거의 사용이 불가능하도록 암호화되고 패스워드가 보호된다.
트랜잭션의 보안은 비밀키에 의존하는데 이 비밀키가 잘못된 사람에게 누출된다면 누구라도 이를 쉽게 복제해서 보안을 손상시키기 위해 사용할 수 있다. 키의 손상은 서버가 비양심적인 해커에 의해 도청 및 조작되었음을 의미하는 메세지를 생성할 것이다. 완벽한 보안 시스템은 사칭자 탐지 및 키 복제 방지를 할 수 있어야 한다.
공개키는 디지털 인증서내에 덧붙여지는데 이는 보안 연결이 요청될 때 서버에서 클라이언트로 보내진다. 이 프로세스는 인증서를 사용하는 서버를 식별한다. 공개키는 무결성, 신뢰성을 인가하며 비밀스런 데이터 전송을 생성하기 위해 데이터를 암호화하는데 사용된다.
CSR(인증서 서명 요청)은 인증서를 생성하기 위한 CA가 필요로 하는 정보를 포함하는데 비밀키의 보충 알고리듬, 공통값 및 서버를 식별하는 정보 들의 암호화된 버전을 포함한다. 이 정보는 국가, 주, 조직, 공통 이름(도메인 이름)과 연락 정보를 포함하며 이에 국한되어 있지 않다.