대칭키
하나의 키
암호화/복호화 할 때 서로 키가 같은경우이다. => 해당 키를 전달하기 위해 평문에 노출될 수 있는 단점
비대칭키(공개키)
한 쌍의 키 (두개) => 하나는 암호화만 가능, 다른 하나는 복호화만 가능
암호화할때와 복호화할 때 키가 서로 다른경우이다.
(클라이언트가 A키, 서버가 B키 가지고 있을 때
ㅡ A키로 암호화한 경우 B키로만 복호화가 가능하고 B키로 암호화한 경우 A키로만 복호화가 가능하다.
/*
공개키는 공개된 곳에 올려놓고 모두 가져가도록 해도 된다.
공개키로 암호화해도 풀 수 있는 것은 개인키(비밀키)만 가능하기 때문이다.
*/
HTTPS
HTTP 프로토콜에서 암호구간(TLS/SSL)을 얹은 프로토콜
TCP 3-way hand shake가 클라이언트와 서버 간에 연결을 설정하여 안정적인 전송 경로를 형성하고,
이후에 SSL/TLS 핸드셰이크가 보안 세션을 설정한다.
데이터를 암호화하여 보내기 위해 보안 조치를 추가한다. 인증서를 통해 서버의 진위를 확인하고, 서로가 함께 알 수 있는 암호화 키를 사용하여 데이터를 보호한다.
=> 비대칭키 방식은 서버의 성능에 영향을 주어 https에서는 대칭키/비대칭키 방식을 혼합하여 사용
그럼 이러한 HTTPS의 방식과 원리를 알기 위해 서명과 인증서에 대한 개념을 먼저 알아보겠다.
디지털 서명
데이터를 송신자가 작성했음을 보장하고, 데이터가 변조되지 않았음을 증명
그림 출처 : https://velog.io/@averycode/HTTPS-%EA%B7%B8%EB%A6%AC%EA%B3%A0-%EB%B3%B4%EC%95%88
서명생성
해시 함수(예를 들어 SHA-256)를 사용하여 데이터의 고정 길이 해시값을 생성
=> 생성된 해시값을 개인키로 암호화하여 서명 생성
서명 검증
클라이언트는 받은 데이터를 동일한 해시 함수 (예를 들어 SHA-256) 로 변환해 해시값을 생성
=> 공개키로 복호화해 원래의 해시값을 복원
/*
해시는 고정된 길이의 고유한 값으로 변환하는 함수이다.
해시값은 파일내용에 따라 고정된 길이의 고유한 값을 가진다.
데이터의 무결성을 보장하는 데 사용된다. 반면 암호화는 데이터를 읽지 못하는데 사용된다.
파일내용이 같으면 같은 값을 가질 수 있다.
| 암호화 | 해시 | |
| 목적 | 데이터의 기밀성 유지 | 데이터 무결성 확인 및 고유 값 생성 |
| 방향성 | 양방향 (복호화를 통해 원본 복구 가능) | 단방향 (원본 데이터 복구 불가능) |
| 키 사용 | 암호화/복호화 시 키 필요 | 키 사용하지 않음 |
| 변환 결과 | 가변 길이 데이터 | 고정 길이 값 |
| 주요 사용 사례 | 통신 암호화, 저장 데이터 보호 | 파일 체크섬, 비밀번호 저장, 디지털 서명 |
| 알고리즘 | AES, DES (대칭) / RSA, ECC (비대칭) | MD5, SHA-1, SHA-256 |
OpenSSL 같은 라이브러리에서 해시와 암호화를 모두 지원하여 데이터 암호화 관련된 기능을 구현할 때 쓰인다.
*/
HTTPS 인증서
SSL 인증서는 클라이언트와 서버간의 통신을 제 3자가 보증해주는 전자화된 문서이다.
사전에 인증기관(CA)과 사이트(서버) 사이에 서버는 SSL 인증서를 발급받기 위해
인증서 내용 데이터( 서버의 공개키와 서버정보 등)를 전달한다.
인증기관에서는 전달받은 데이터를 해시값으로 변환한 뒤 해시값을 인증기관(CA)의 개인키로 암호화 진행=> 디지털 서명 생성.
서명한 이 정보가 서버의 인증서가 된다. 서버는 인증기관으로부터 전달받은 인증서(서버정보 + 공개키 + CA의 디지털 서명) 를 서버에 저장해둔다.
클라이언트가 서버에 접속하면 서버는 클라이언트에게 이 인증서 정보를 전달하게 되는데
브라우저는 신뢰된 CA 기업의 공개키는 모두 보유하고 있어 브라우저가 보유한 검증된 CA 공개키에 의해 복호화가 가능하다.
/*
SSL 인증서에는 서비스의 정보(인증서를 발급한 CA, 서비스의 도메인 등)와 서버의 공개키가 포함되어 있다.
이 내용은 제 3자인 CA(Certificate Authority, 공개키를 저장해주는 신뢰성이 검증된 민간 기업)에 의해 암호화된다.
*/
SSL/TLS handshake
1. Client Hello
클라이언트가 서버에 접속을 시도한다.
사용 가능한 암호화(방식)/해시 알고리즘과 random 값을 서버에게 전달
random 값은 추후 공통키를 만드는 과정에서 사용된다.
2. Server Hello
서버가 클라이언트에 대응한다.
전달받은 암호화/해시 방식 중 우선순위 가 높은 옵션(cipher suite)을 선택해서 이를 클라이언트에게 전달
이로써 클라이언트와 서버 모두 2개의 random 값 (난수) 가지고 있음.
/*
RSA 같은 키 교환 알고리즘 및 AES 같은 암호화 알고리즘 그리고 SHA-256 같은 해시 알고리즘 등
지원가능한 암호 스위트 목록을 보내주면 선택된다.
*/
3. Certificate
서버는 자신을 증명하기 위해 (자신의 공개키가 적힌) 서버 인증서 전달.
사전에 인증기관으로부터 받은 디지털 서명을 함께 전달
클라이언트는 공개된 Root CA의 공개키를 통해 디지털 서명을 복호화한다.
복호화가 가능하다면 검증이 된 것이므로 인증서에 적힌 공개 키(Public 키)를 사용할 수 있다.
4. Client Key Exchange
클라이언트의 브라우저는 premaster secret 이라고 하는 무작위 바이트 문자열을
인증서에 적힌 공개키로 암호화하여 서버로 전송한다.
5. 대칭키(Session Key) 확인
서버는 사이트의 개인키(비밀키)로 브라우저가 보낸 premaster secret 값을 복호화하여 추출할 수 있다.
클라이언트와 서버는 각자 가지고 있는 random 값과 premaster secret를 이용하여 대칭키로 활용할 세션 키와 MAC키를 생성하고 이 공통 키를 사용하자고 마지막 확인한다.
6. 이후 송수신 과정 (HMAC 플로우)
클라이언트는 MAC 키를 통해 데이터의 MAC 값을 구하고 MAC값과 데이터를 Session key로 암호화하고 서버로 전달한다. 서버는 MAC값과 데이터를 Session Key로 복호화하고 똑같이 데이터를 MAC키로 계산하여 전달받은 MAC값과 같은지 확인한다.
/*
해싱할 때 고정된 길이의 고유한 값으로 변환할 뿐 기본적으로 키가 필요하지 않지만
HMAC은 해시함수와 대칭키를 결합한 방식으로 키와 메세지를 결합한 후 해싱한다.
이렇게 함으로써 무결성 뿐만 아니라 인증 까지도 보장된다.
TLS/SSL 뿐만 아니라 API 인증 등의 클라이언트와 서버가 키를 공유하여 무결성과 인증을 확인할 때 사용된다.
*/
이런식으로 브라우저와 서버는 주고받는 데이터를 암호화하고 복호화한다.
위의 SSL handshake 과정은 글마다 다르지만 구현체마다 다양한 옵션을 가지고 있어서 그런 것이라고 한다.
원리는 인증서가 유효하였을 때 클라이언트는 대칭키를 생성하고
서버는 개인키를 사용해서 대칭키를 복호화하여 이를 이후 클라이언트와 서버 간의 데이터 전송 시 사용한다는 것이다.
/*
비대칭키 암호화 방식은 대칭키 방식 보다 매우 느리다.
한번 교환하면 대칭키를 이용하게 된다.
*/
암호화와 해시의 특성을 결합한 방식으로, HMAC (Hash-based Message Authentication Code)가 있다.
HMAC은 해시 알고리즘과 암호화 키를 결합하여 메시지 무결성과 인증을 제공
참고
https://velog.io/@alscjf6315/HTTPS-%EC%9D%98-%EB%8F%99%EC%9E%91%EC%9B%90%EB%A6%AC
https://inuplace.tistory.com/1086
https://brunch.co.kr/@growthminder/79
https://brunch.co.kr/@sangjinkang/34
https://velog.io/@averycode/HTTPS-%EA%B7%B8%EB%A6%AC%EA%B3%A0-%EB%B3%B4%EC%95%88
'프로그래밍 기초' 카테고리의 다른 글
| DNS (0) | 2024.09.30 |
|---|---|
| Github 기본 (0) | 2024.09.25 |
| 0.웹에 관한 중요 키워드 (0) | 2024.07.02 |