.

일반적인 해시 함수(Hash Function)는 임의의 유한한 길이를 가진 데이터를 고정된 길이의 데이터로 매핑하는 함수이다.

x

👇🏻

|Hash function|

👇🏻

y = h(x)

해쉬 함수 h는 압축성과 계산 용이성의 성질을 가지고 있다.

• 압축성(compression) : 임의의 유한 길이의 입력 비트 스트링 x를 고정된 길이의 출력 비트 스트링 h(x)로 변환한다.
• 계산 용이성(ease of computation) : 주어진 h와 x에 대하여 h(x)를 계산하기 쉽다.

해시 함수는 출력값으로 고정된 길이의 데이터를 생성하기 때문에 서로 다른 입력값이 동일한 해시값을 출력할 수 있지 않을까?

그래서 암호학적 해시 함수(Cryptographic Hash Function)는 아래 3가지 성질을 만족해야 한다.

• 역상 저항성(Preimage resistance) : 임의의 출력값 y가 주어졌을 때, y = h(x)를 만족하는 x 값을 찾는 것이 계산적으로 불가능하다.
• 제 2 역상 저항성(Second preimage resistance) : 주어진 입력값 x에 대해 h(x) = h(x'), x != x' 를 만족하는 x'를 찾는 것이 계산적으로 불가능하다.
• 충돌 저항성(Collision resistance) : h(x)에 대해 h(x) = h(x')를 만족하는 x와 x'를 찾는 것이 계산적으로 불가능하다. ex) 전자 서명

충돌 저항성을 만족하면 > 제 2 역상 저항성도 만족하게 된다.

생일 문제(Birthday problem)

P(N) : N명 중 생일이 같은 사람이 두 명 이상일 확률

P(N) = 1 - (N명의 생일이 모두 다를 확률)

P(N) = 1 - (365/365) * (364/365) * ... * ((365-(N-1))/365) > 1/2 을 만족하는 최솟값 N은 23이 된다.

(100명의 사람이 존재할 때, 생일 같은 사람이 두 명 이상일 확률을 생각해본다면, 흔히 N = 50이 답일 것이라 생각하지만 정답은 그 보다 적은 사람이 존재할 때이다.)

생일 공격(Birthday attack)

- 암호학적 해시 함수의 해시 충돌을 찾아내는 암호해독 공격으로 생일 문제의 확률적 결과를 기반으로 한다. 생일 문제에 따르면 해시 함수의 입력값을 다양하게 할수록 해시값이 같은 두 입력값을 발견할 확률이 빠르게 증가하기 때문에 모든 값을 대입하지 않고도 해시 충돌을 찾아낼 확률을 충분히 크게 만들 수 있다.(wiki)

👉🏻 서로 다른 입력값 x, x'에 대해 h(x) = h(x')를 만족하는 x와 x'을 찾는 문제이다.

- 해시 함수 h의 출력이 n비트일 때, h의 충돌을 발견할 확률이 절반이 넘기 위한 복잡도는 약 n/2비트이다.

👉🏻 128bit 암호키는 256bit 해시 함수와 동일한 효과를 보인다.

해시 함수의 종류는 다음과 같다.

MD(Message Digest)

MD2 -> MD4 -> MD5로 발전되었다. 그러나 128비트의 해시값은 너무 짧아 해시값의 충돌을 발견하는 방법이 고안되어 현재는 MD5를 제외하고 사용되지 않고 있다. (MD5는 2005년 깨졌으나, 아직 사용되는 곳이 존재함)

SHA(Secure Hash Algorithm)

SHA는 NIST에서 만들어진 160비트의 해시값을 가지는 일방향 해시 함수이다. SHA-224, SHA-256, SHA-384, SHA-512는 SHA-2라고도 부른다. 미국 국립표준기술연구소는 SHA-3을 공모하여 2015년 8월 SHA-3 암호화 해시 함수 표준을 발표했다.

LSH

국내에서 개발된 암호화 해시 함수이다. 다양한 소프트웨어 환경에서 국제 표준(SHA2/3) 대비 2배 이상의 성능을 가지고 있다.

참고

https://continuetochallenge.tistory.com/86

SSL(Secure Socket Layer)에서 발전된 프로토콜이 TLS(Transprot Layer Security)이다. 웹 응용 프로그램과 서버 간의 정보를 암호화하고 이메일이나 VoIP 에도 사용되고 있다. 기밀성, 데이터 무결성, 인증, 전자 서명이 보장되지만 SSL과 TLS는 상호 운영되지 않는다.

아래는 SSL/TLS 프로토콜에서 사용되는 기술이다.

• 하나의 키로 암/복호화를 수행하는 대칭 키 암호화 방식
• 한 쌍의 키 페어로 암/복호화를 수행하는 비대칭키 암호화 방식
• 인증
• 전자 서명
• 전자 서명을 해주는 제 3의 인증 기관(CA: Certificate Authority)
• 공개 키를 안전하게 전달하고 공유하기 위한 프로토콜
• 암호화된 메시지의 변주 여부를 확인하는 메시지 무결성(인증) 알고리즘

SSL/TLS는 비대칭/대칭 암호화를 모두 사용한다. 클라이언트와 서버는 인증 과정에서 공유 보안 키 생성을 위한 키 분배의 문제점을 막기 위한 비대칭 암호화 기술과 빠른 대칭 암호화의 공유키를 사용한다.

아래는 SSL/TLS handshake 과정이다. (두 번째 그림은 최신 TLS 1.3 버전이다)

SSL/TLS handshake 과정이 시작되기 전 TCP 3-way-handshake 과정이 끝난 후이다.

(클라이언트)1. 클라이언트는 서버에 접속하여 Client Hello 단계에서 다음 정보를 보낸다.

- 클라이언트가 사용하는 SSL or TLS 버전 정보

- 클라이언트가 지원하는 알고리즘 결합 정의(Cipher Suite)

- 클라이언트가 순간적으로 생성한 임의의 난수(숫자)

- 기타 확장 정보(extension)

(서버)2. 서버가 클라이언트에게 Server Hello 로 응답하며 정보를 제공한다.

- 클라이언트의 암호화 방식 정보 중에서 서버도 지원할 수 있고 선택한 암호화 방식(Cipher Suite(밑 부분에 설명되어 있다))

- SSL/TLS 인증서 (+ 공개키)(인증서는 CA의 비밀 키로 암호화되어 발급된다)

- 서버가 순간적으로 생성한 임의의 난수(숫자)

- 클라이언트 인증서 요청(선택 사항. 만약 클라이언트의 인증서가 필요한 시점에서 잘못된 인증서가 오거나 없다면 통신이 취소된다)

(클라이언트)3. 클라이언트는 서버의 SSL 인증서를 믿을 수 있는지 확인한다.

- 클라이언트에게는 CA의 정보와 CA가 만든 공개 키를 이미 가지고 있다. 서버가 보낸 인증서의 진위 판별을 위해 내장된 CA 공개 키로 암호화된 인증서를 복호화함으로써 인증할 수 있다. (인증서에 담긴 서버 공개 키도 획득한다)

(클라이언트)4. 클라이언트는 자신이 생성한 난수와 서버의 난수를 이용하여 Premaster Secret(PMS)을 만든다.

- 서버 인증서에 담긴 공개 키로 이것을 암호화하여 다시 서버로 전송한다. 생성된 PMS 키는 후에 데이터를 주고 받을 때 대칭 키로 이용된다)

(서버)5. 서버는 비밀 키를 이용하여 PMS 값을 복호화한다.

- 복호화한 값을 master secret 키로 저장한다. 이를 이용하여 클라이언트와의 연결에 고유한 값을 부여하기 위한 session key를 생성한다. session key는 대칭 키 암호화에 사용될 키이다. 이 키를 이용하면 클라이언트-서버 사이에 주고 받는 데이터를 암/복호화할 수 있다.

- 클라이언트 역시 PMS 키를 master secret 키로 만들어 session key를 생성한다. (대칭 키임을 인지)

이제 SSL/TLS handshake가 완료되어 종료되고, HTTPS 통신이 가능해진다. 클라이언트와 서버는 session key를 이용해 암/복호화를 하며 HTTPS 프로토콜을 통해 데이터를 주고 받는다. HTTPS 통신이 종료되면 session key는 폐기한다.

handshake 과정에서 클라이언트와 서버가 통신하기 위해서는 동일한 CipherSpec에 동의해야 한다.

CipherSpec이란 암호화 알고리즘 + 메세지 인증 코드(MAC) 알고리즘을 의미하며 사용되는 알고리즘의 결합을 정의하는 것이 CipherSuite이다.

ex) CipherSuite TLS_{키 교환 암호 알고리즘}_{인증 방법}_WITH_{대칭 암호화 기법}_{데이터 무결성 체크 방법(해시 알고리즘)}

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(MAC)

참고

https://www.ibm.com/docs/ko/ibm-mq/9.1?topic=mechanisms-cryptographic-security-protocols-tls 

https://brunch.co.kr/@sangjinkang/38