1. 개요
IoT의 전반적인 개념에 대해서는 앞서 많은 이야기가 되고 있는 것 같습니다. 그래서 이번에는 IoT를 위한 기술 중, 별 대단한 신기술은 아니지만 어쩌면 굉장히 중요한 기술이 될 수 있는 SSL에 대하여 언급해 보고자 합니다.
2. SSL 의 역사
SSL은 Secure Socket Layer의 약자로 Netscape 사에서 개발하였습니다. 하지만 최초의 버전인 1.0은 공개적으로 release 되지 않았습니다. 1995년 2월에는 몇가지 결함이 포함된 SSL 2.0이 release 되었으며, 1996년에는 비로소 완전체라고 할 수 있는 3.0이 release 되었습니다. 그 후 1999년 1월에 이 SSL 3.0을 새롭게 정의한 TLS 1.0이 release 됩니다. TLS 1.0은 RFC 2246, TLS 1.1은 RFC 4346, TLS 1.2는 RFC 5246에 정의되어 있습니다.
SSL은 TCP/IP 의 Transport Layer의 암호화 방식입니다. 따라서 HTTP 프로토콜 뿐 아니라 NNTP, FTP, XMPP 등의 프로토콜에도 다양하게 적용할 수 있습니다. 이 때문에 TLS(Transport Layer Security)라는 이름으로 불리게 된 것은 아닐까 하네요. 보통 SSL/TLS로 묶어서 표현하기도 하지요.
3. Private key, public key
SSL 인증에 대한 이야기를 하다 보면 private key(개인 key)와 public key(공개 key)에 대한 이야기를 빼놓을 수 없습니다.
이 방식의 특징은, 하나의 key로 암호화를 하면 해당되는 쌍의 다른 key 로만 해독이 가능하다는 것입니다. 예를 들어, (가)와 (나)가 한 쌍일 때, (가) key 로 암호화한 경우 (나) key로만 풀 수 있으며, (나) key 로 암호화한 경우 (가) key 로만 풀 수 있다. 이러한 key 는 소수 (prime number) 기반으로 생성되며, 길이, 즉 bit 가 길수록 암호화는 강해집니다.
Private key, public key는 위와 같은 이론을 바탕으로 하고 있다. 한 key는 개인이 비공개로 보유하고, 또 다른 key는 모두에게 공개합니다. 다른 사람들은 공개된 public key를 이용하여 그 개인에게 암호화된 내용을 전송한다. 이 내용은 private key를 가진 당사자만 풀 수 있습니다.
만일 내용을 private key를 이용하여 암호화하여 보낸다면, public key를 가진 모두가 그 내용을 해독하여 볼 수 있게 됩니다. 그러면 private key를 이용하여 암호화하였다는 것이 증명되고, 이는 곧 특정 개인이 보낸 메세지라는 것을 증명하게 됩니다.
4. 인증서
앞에서 public key 는 이름 그대로 공개한다고 했습니다. 그런데 public key를 받은 쪽에서, 그 쪽에서 보낸 public key가 정말 맞는지 의심을 할 수 있습니다. 그래서 그 역할을 제 3자가 합니다. 특정 key 가 그 쪽에서 보낸 것이 맞다는 것을 서명한 인증서를 발급하는 것입니다. 인증서에는 소유자 이름, 이메일, 그리고 인증서 용도, 유효기간, 위치 등등의 정보가 저장되어 있는데, 이러한 정보를 public key 와 public key 의 hash 값과 같이 저장하여 인증서를 생성합니다.
5. X.509
SSL 과 인증서는 서로를 표현하는 단어라고 할만큼 밀접한 관계가 있습니다.
이 글에서 인증서는 공개키 기반 인증서를 기준으로 설명합니다. 이 공개키 인증서는 개인키를 소유한 사람, 또는 장치나 서비스의 ID 에 공개키를 바인딩하는 문서입니다. access 의 필요 조건으로 인증되어야 하는 개별 주체들의 암호들을 서버가 관리할 필요가 없다는 것이 이 방식의 장점이라고 할 수 있습니다. 단지 서버는 인증서 발급자와 신뢰를 설정하기만 하면 됩니다.
이러한 통신 과정에서 전자 서명을 위한 인증서는 디지털 형태의 표준화가 필요한데 현재 가장 널리 사용되는 표준은 X.509 형식의 인증서입니다. 만일 인증서를 발급할 때 인증서에 들어가는 항목의 종류와 그 항목의 값들을 임의로 넣는다면 인증서를 사용하는 사용자마다 다른 형식의 인증서를 가지고 있게 될 것입니다.
1988년 X.500 표준의 하나로 시작된 X.509 는 1993년 2.0 이 발표되었습니다. 인증기관의 고유 식별자와 주체고유 식별자가 추가되었지요. 그리고 1996년에 현재 사용되는 3.0 이 발표되었습니다.
PGP 와 같이 상호 신뢰를 바탕으로 하는 모델과 달리 X.509 는 꽤나 엄격한 수직적 구조를 채택하고 있습니다. 즉, 하나의 인증 기관을 정점으로 트리 구조를 가지고 있습니다. 이 방식의 불편함을 해소하기 위하여 몇몇 신용할 수 있는 Root CA 끼리는 상호 인증과 자가 인증을 허용하고 있습니다.
X.509 인증서는 다음과 같은 형식을 가지고 있습니다.
| 항목 | 설명 | 필수여부 |
| Version | 인증서의 버전 (3.0) | 필수 |
| SerialNumber | 인증서의 고유숫자 | 필수 |
| Signature | 발급자 서명 | 필수 |
| Issuer | 발급자 정보 (DN 형식) | 필수 |
| Validator | 인증서의 유효기간, 시작/종료 날짜 | 필수 |
| Subject | 주체의 정보 (DN 형식) | 필수 |
| SubjectPublicKeyInfo | 주체의 공개키 | 필수 |
이전 버전과 3.0 의 차이는 Extension 이라는 섹션이 추가된 것입니다. Extension 은 여러 개의 항목으로 구성되어 있으며 필수적인 항목이 아니라 추가적인 항목을 넣고자 할 때 사용합니다.
| 항목 | 설명 | 필수여부 |
| SubjectAtName | 주체의 다른 이름 (DN 형식 아님) | 필수/선택 |
| PolicyMappings | 다른 정책과 연결할 수 있는 정책 정보 | 선택 |
| NameConstraints | 선택 | |
| PloicyConstraints | 인증서 경로의 제약 사항 | 선택 |
| IssuerAtname | 발급자의 다른 이름 (DN 형식 아님) | 선택 |
| AuthorityKeyIdentifier | 발급자의 키를 나타내는 키의 이름 | 선택 |
| SubjectKeyIdentifier | 주체의 키를 나타내는 키의 이름 | 선택 |
| BasicConstraints | 제약사항 | 필수/선택 |
| CRLDistrubutionPoints | 인증서의 CRL 을 얻을 수 있는 곳 | 선택 |
| KeyUsage | 인증서의 공개키가 사용되는 보안 서비스 종류 | 선택 |
DN 이란 Distinguished Name 의 약자입니다. 이 형식으로 인증서의 주체와 발급자의 정보 등이 들어갑니다. 다음을 참고하세요.
| DN | 항목 | 설명 | 예 |
| C | countryName | 국가코드 (2자리) | KR |
| ST | stateOrProvinceName | 주 이름 (우리나라는 시 이름) | SEOUL |
| L | localityName | 시 이름 (우리나라는 구 이름) | MAPO |
| O | organizationName | 소속 기관명 | LG |
| OU | organizationUnitName | 소속 부서명 | TWINS |
X.509 인증서의 형식은 ASN.1 즉 Abstract Syntax Notation One 이라는 명명규칙을 따릅니다. 이 ASN.1 규칙은 매우 복잡한데 마치 C언어를 연상케 합니다. 변수를 가지고 있고 구조체를 사용합니다. 인증서의 각 항목은 OID 라는 일련 번호로 나타낼 수 있고 데이터들은 ASN.1 타입의 데이터로 표현됩니다.
이 ASN.1 형식으로 되어 있는 X.509 인증서를 파일로 저장할 때 두가지 종류로 저장할 수 있습니다.
- PEM
- DER
이제까지 스터디한 내용은 여기까지입니다. 다음에 또 이어서 X.509 인증서에 대해서 적어보도록 하겠습니다.
