CA

l SSL Certificate?

디지털 인증서라고도 하는 SSL(보안 소켓 계층) 인증서는 브라우저 또는 사용자의 컴퓨터와 서버 또는 웹사이트 간에 암호화된 연결을 수립하는 데 사용됩니다. SSL 연결은 인증되지 않은 사용자의 방해로부터 각 방문(세션) 중에 교환된 중요한 데이터(예: 신용카드 정보)를 보호합니다.

 

출처: https://www.digicert.com/kr/ssl-certificate/

 

l Web trust?

웹트러스트(WebTrust) 인증은, 공인 인증서 발급 기관 CA 에서 해당 업무를 수행할 때 투명하고 신뢰성 있는 절차 및 발급 업무를 수행하고 있는지 검증하여 인증을 부여하는 제도이며, 국제표준(Trust Services Principles) 에 따라 검증을 통과한 경우, 대부분의 인증 관련 시스템(운영체제 및 웹브라우져등)에서 공인된 신뢰 기관으로 등록됩니다.  (사설 인증서와 국제 공인 인증서 차이)

 

출처: https://www.securesign.kr/guides/kb/53

 

l LDAP?

LDAP은 Lightweight Directory Access Protocol의 약자로, 인터넷 기반의 분산 디렉터리 서비스를 제공하는 공개된 프로토콜입니다. 인터넷 기반의 공개 프로토콜이고 이 분야의 표준이나 다름없어서, 각종 애플리케이션에서 기본적으로 지원하고 사용하는 프로토콜입니다. 마치 HTTP가 HTML 문서를 주고받는 표준인 것처럼, LDAP이 디렉터리 서비스를 위한 표준인 것이지요.

 

디렉터리 서비스

디렉터리 서비스도 제게는 좀 생소한데, 쉽게 생각하면, DNS도 디렉터리 서비스의 일종입니다. 어떤 이름을 기준으로 대상을 찾아 조회하거나 편집할 수 있는 서비스인데요, DNS의 경우 도메인 이름을 기준으로 IP주소 같은 데이터를 접근하는 디렉터리 서비스라고 볼 수 있습니다.

사용자, 시스템, 네트워크, 서비스, 애플리케이션 등의 정보를 (주로 트리 구조로) 조회하거나 관리합니다. 회사에서 구성원의 조직도나 팀별 이메일 주소 등도 LDAP 서비스로 관리하고는 합니다. 흔하게는 특정 영역에서 이용자명과 패스워드를 확인하여 인증하는 용도로도 쓰입니다.

제가 예전에 다니던 회사도 사내 조직도 정보나 각 구성원의 인트라넷 아이디와 패스워드를 LDAP 서비스로 관리했기에, 사내 관리 툴을 만들려면 LDAP 프로토콜로 인증처리를 붙였던 기억이 나네요. 이렇게 구성원 주소록도 디렉터리 서비스의 관리 대상이 될 수 있고, 시스템을 구성하는 서비스에 대한 정보도 담고 관리할 수 있습니다. 사실상 아무런 데이터가 들어가도 무방해 보입니다. 무언가 트리구조로 검색하고 편집하기 좋은 경우라면 말이죠.

 

흔한 LDAP 클라이언트

회사에서 관리하는 임직원 데이터베이스 등은 흔히 LDAP 서버로 운영되므로, 서버는 그걸 생각하면 쉽고, 클라이언트의 경우, 각종 주소록 애플리케이션을 생각하면 쉬울 수 있겠습니다. 당장 우리가 쓰는 스마트폰들도 내부적으로 LDAP 클라이언트가 들어 있어서, 어떤 주소록 용도의 LDAP 서버에 연결해 내 스마트 폰의 주소록과 쉽게 동기화해 쓸 수 있습니다.

 

Lightweight?

이 경량의 의미가, 프로토콜 스펙상의 가벼움을 얘기하는 것이 아니라, 통신 네트워크 대역폭 상의 가벼움을 의미하는 것이더군요. LDAP의 부모인 DAP 프로토콜에서 인터넷 프로토콜 통신 부분만 떼어서 발전된 게 LDAP인데, 인터넷 프로토콜로 데이터를 조금만 주고받아도 되게끔 설계됐다고 합니다.

 

요즘은 LDAPv3를 사용.

 

바이너리 프로토콜

LDAP은 기본적으로 바이너리 프로토콜입니다. 메시지 내용이 ASN.1이라는 언어로 메시지를 표현하고, 이 메시지를 BER(Basic Encoding Rules)라는 포맷으로 인코딩하여 주고받습니다. 이 BER인코딩이 바이너리라서 이 내용을 텍스트로 알아볼 수는 없습니다. HTTP나 SMTP처럼 기본적으로는 텍스트 프로토콜이고, 중간중간 바이너리 데이터가 인코딩돼 들어있는 것과는 대조적입니다. 텍스트 포맷인 HTTP 프로토콜은 오가는 메시지의 대강의 내용은 사람이 눈으로 알아볼 수 있지만, LDAP은 그렇지 않은 셈입니다.

게다가 ASN.1과 BER도 생소할 수 있는데, 대충 생각해보면, JSON과 그걸 나름의 인코딩 스킴으로 표현한 MessagePack과의 관계가 아닐까 생각해 봅니다.

 

 

비동기 프로토콜

HTTP 프로토콜의 경우, 기본적으로는 클라이언트가 요청을 보내고, 해당 요청에 대한 응답을 받고자 기다립니다.

LDAP의 경우에는 세션(커넥션) 하나를 열어서 여러 메시지 요청을 보낼 수 있고, 각각의 요청에 대한 응답이 다른 시점에 올 수 있습니다. 응답마다 어떤 요청에 대한 응답인지에 대한 아이디가 있을 테고요. 요청 메시지들의 순서와 그에 대응하는 응답 메시지들의 순서가 다를 수도 있습니다.

 

LDAP의 디렉터리 구조

LDAP 서버에는 여러 엔트리(entry)가 트리구조로 들어있습니다. 각각의 엔트리는 다수의 속성을 갖고, 각 속성은 (이름, 값+) 형태로 있습니다. 이름 하나에 한 개 이상의 값이 바인딩될 수 있습니다. 각 엔트리는 DN(Distinguished Name)이라는 고유값으로 지칭됩니다. 고유값인데, 그 값에서 어디에 속한 엔트리인지 파악할 수 있습니다. 디렉터리의 파일이라고 치자면,

/home/hatemogi/ldap.md

같은 전체 경로가 DN이라고 볼 수 있고, 그중에 /home/hatemogi 이 부분이 그 상위 엔트리의 DN인 셈입니다.

출처:https://medium.com/happyprogrammer-in-jeju/ldap-%ED%94%84%ED%86%A0%ED%86%A0%EC%BD%9C-%EB%A7%9B%EB%B3%B4%EA%B8%B0-15b53c6a6f26

 

ASN.1?

우리는 인터넷을 통해 다양한 운영체제 시스템에 접속할 수 있게 되었습니다.

즉 이기종 시스템간에는 데이터를 메모리에 저장하는 특성이 틀려 복잡한 데이터를 주고 받을 때 상대방 시스템에 잘못된 데이터를 받을 가능성이 높습니다. 이러한 문제점을 해결하기 위해서 공통화된 데이터 표현 문법을 만들게 되었고 이를 통해서 ASN.1이 생겨나게 되었습니다.

즉 데이터 구성을 표현하는 문법(언어)입니다. 다음과 같은 문법으로 표현이 됩니다.

 

ASN.1은 주로 인증서(인터넷 뱅킹) 사용됩니다.

인터넷 뱅킹에 사용되는 인증서가 ASN1.에 의해서 표현된 문법구조를 따라서 데이터가 구성되고 이것이 Encoding 되어 인증서라는 파일로 존재하게 되는 것입니다.

[인증서 기본 포맷]

 

Ans.1 사용하려면 ans.1 파일을 c, c++, java, c# 형태의 소스로 출력하고 우리는 해당 소스를 첨가하여 프로그래밍 하면 된다.

출처: https://coinz.tistory.com/21

 

l  ECC(Elliptic Curve)

타원곡선 암호화 알고리즘(ECC)은 비트코인의 소유권 증명, 미국 정보의 내부 통신 보호, Apple의 iMessage 서비스에도 DNS 정보를 암호화하는데 사용되고 있다. 또한 IoT 경량 암호화로 ECC 알고리즘이 주목받고 있으며, 간편결제 인증에서 ECC 암호화를 채택하는 사례가 등장하고 있다

타원곡선 암호(ECC)는 공개키 암호화 방식 중 하나로 유한체(Finite field) 위에서의 타원곡선의 대수적

구조를 기반으로 한 이산로그문제에 착안해 만들어졌다. 타원곡선 암호는 기존의 공개키 암호에 비해 더

적은 비트로 동일한 안전성을 얻을 수 있고 빠른 속도로 암호화를 처리하며, 키(key) 관리가 용이한

장점이 있다.

 

l  CA 구성요소

1)      RootCA 2)      CA 3)      RA 4)      WebRA 5)      OCSP

 

l  ARL VS CRL

-       ARL: 인증기관 폐지 목록

-       CRL: 사용자 인증서 폐지 목록

 

l  등록기관(RA – Registration Authority)

-       신원확인, 고객데이터 유지 등 인증기관의 입증을 대행하는 등록기관

-       사용자의 인증서 발급 요청을 등록하고, 신원확인 기능을 수행

 

l  온라인 인증서 상태 프로토콜(OCSP – Online Certificate Status Protocol)

전자 서명 인증서 폐지 목록의 갱신 주기성 문제를 해결하기 위해 폐지/효력 정지 상태를 파악하여 사용자가 실시간으로 인증서를 검증할 수 있는 프로토콜.

 

 

l  키 생성 시스템(KGS – Key Generation System)

키 생성 정책에 따라 공개키 및 개인키를 생성.

 

l  시간값 인증(TSA – Time Stamp Authority)

전자문서 및 전자서명에 대한 시점확인 증명데이터를 활용해, 특정 시간에 해당문서가 존재했다는 것을 증명, 데이터 정확성 위조 여부 확인

출처: http://blog.naver.com/PostView.nhn?blogId=rasede&logNo=221388543434&parentCategoryNo=&categoryNo=&viewDate=&isShowPopularPosts=false&from=postView

 

l  CRL(Certificate Revocation List)

CRL이란 인증서 폐기 목록입니다. 다시말해 현재 사용중인 인증서가 만료된건지 정상인지를 판단 할 수 있는 신뢰 할 수 있는 인증서 폐기목록이라는 말이지요.

HTTPS로 접속을 시도한 후 클라이언트는 인증서에 기록된 CRL주소에서 CRL List를 다운로드 받아 인증서의 폐기여부를 확인하게 됩니다. 만약 인증서가 폐기되지 않았다면 인증서의 만료와 관련된 무결성이 확인이 되는 것이죠.

[단점]

하지만 CRL은 클라이언트에서 매우 큰 CRL (인증서 폐기목록) 을 모두 다운로드 받아 확인해야 하는 단점을 가지고 있습니다. 그렇기 때문에 처리시간이 매우 느리며 CA기관에서 상기 항목을 계속해서 갱신하고 클라이언트 또한 계속 갱신하여 확인해야 합니다.

 

l  CRT의 동작방식은 아래와 같습니다.

-       HTTP 또는 LDAP을 이용, 인증서를 통해 교부 받은 URL을 통하여 CRL을 요청합니다.

-       CA는 요청을 받은 이후 CRL List (인증서 만료목록) 를 응답합니다.

-       브라우저는 CRL정보를 파싱하고 현재 접속하려는 사이트의 인증서가 CRL에 포함되어 있는지 점검합니다. (CRL에는 만료인증서에 대한 시리얼 정보가 포함되고 있으며, 체크하려는 인증서의 시리얼이 CRL에 포함되어 있는지 점검합니다.)

 

l  OCSP

OCSP는 RFC2560에서 소개되었으며 목적은 인증서의 상태를 실시간으로 체크하기 위한 프로토콜이라고 보시면 되겠습니다. OCSP는 인증서의 시리얼을 통하여 실시간으로 인증서의 만료여부를 CA 인증서 DB에 직접 요청합니다. 이렇게 OCSP는 실시간으로 인증서의 만료여부를 확인 할 수 있으며 CRL과 같이 불필요한 목록을 모두 받아 볼 필요가 없어 그 속도가 빠릅니다.

OCSP서버는 요청을 받아 확인 후, 좋음 (good), 만료 (revoked), 알수 없음 (unknown) 의 세가지 값으로 응답하여 줍니다. 만약 인증서가 유효하지 못한 경우에는 error code를 응답해 주게 되고요.

OCSP는 CRL의 단점을 매우 많이 개선하였습니다.

출처: https://rsec.kr/?p=386

 

l  WebRA

cmp(X)

 

l  CMP

.exe