OAuth를 이용하기 위해 Client를 등록하는 과정에서
어플리케이션의 형태를 Android로 선택하니 SHA-1를 등록하는 부분이 등장했습니다.
일단 SHA-1에 대해 찾아보니
인터넷 보안 프로토콜과 공개키 인증서에도 적용되고 있는 매우 중요한 암호 알고리즘
이라고 합니다.
결국 암호학에 대해서 전체적으로 정리를 해보려고 합니다.
야크의 털 깎기가 되기 전에 SSL과 HTTPS도 개념을 짚고 넘어갑니다.
(개인 프로젝트 때 궁금했던 SSL)
🔐암호학 (cryptography)
crypto(비밀) + graphy(방법) = 비밀을 다루는 방법
비밀을 지키기 위한 요소들
- 암호화된 내용을 알 수 없어야 한다 -> 기밀성
- 내용이 원본과 같다는 확신이 있어야 한다 -> 무결성
- 권한이 있는 사람만 접근할 수 있다 -> 인증
암호가 동작하는 기본적인 흐름
<그림출처: 생활코딩>
- 평문 : 보호되고 있지 않은 데이터
- 암호문 : 암호화된 데이터
- 평문을 암호문으로 만드는 것을 암호화(encryption)
- 암호문을 평문으로 만드는 것을 복호화(decryption)
옛날에는 알고리즘을 공개하지 않고 평문을 보호했지만
현재는 알고리즘을 공개해 검증을 받고 "비밀정보"를 섞습니다.
여기서 "비밀정보"를 key라고 합니다.
암호법
암호법은 크게 두가지 분류가 있습니다.
- 양방향 암호화 방식
암호화, 복호화 모두 할 수 있으며 정보를 감추는 기밀성에 초점이 맞추어져 있습니다.- 대칭키 : 암호화와 복호화 모두 같은 key로 가능합니다.
ex) AES, Twofish - 비대칭키(or 공개키) : 암호화, 복호화 모두 다른 key를 가져 2개의 key가 필요합니다.
ex) RSA
- 대칭키 : 암호화와 복호화 모두 같은 key로 가능합니다.
- 단방향 암호화 방식
평문을 암호문으로 만드는 암호화만 가능합니다.
무결성에 초점을 맞추었습니다.
ex) MD5, SHA
🔪단방향 암호화
= Hash
= 다지다
= 원래 상태로 되돌릴 수 없다
앞서 단방향 암호화는 무결성에 초점을 맞추었다고 했습니다.
즉 어떠한 정보가 원본으로부터 훼손되거나 조작되지 않는 것을 의미합니다.
파일을 업로드하면
그 파일의 내용을 MD5로 암호화하여
게시자가 올린 파일과 같은 파일인지 확인할 수 있는 사이트가 있습니다.
업로드 하여 위 파일 아래에 있는 md5와 같은 내용인지 확인하면 됩니다.
위와 같이 MD5는 다운로드 받은 파일이 원본 파일과 같은 것인지 확인하는 무결성에 초점이 맞추어져 있습니다.
무결성 체크는 아래와 같은 상황에서 주로 합니다.
- 전자서명할 때
- 파일을 식별할 때
- 사용자의 비밀번호를 서버에 안전하게 저장할 때
- 가상화폐, 비트코인 등을 채구할 때 작업 증명
🔑양방향 암호화 방식
-
대칭키: 하나의 키로 암호화와 복호화
가장 유명한 AES 대칭키 알고리즘
대칭키는 MY PASSWORD입니다.
대칭키를 위와 같이 두고 암호화를 하면 아래와 같은 결과가 나옵니다.
암호화된 내용을 다시 대칭키를 가지고 복호화하면 "메롱"이라는 결과가 나옵니다.
보면 암호화와 복호화 모두 MY PASSWORD라는 같은 키로 진행된 것을 확인할 수 있습니다. -
비대칭키 혹은 공개키
양방향 암호화 방식 중 하나인 비대칭키 혹은 공개키는
암호화, 복호화에 서로 다른 키를 사용한다고 말했습니다.공개키(public key) : 평문 -> 암호문
비공개키(private key) : 암호문 -> 평문
반대인 비공개키로 암호화를 공개키로 복호화를 할 수 있습니다.대칭키 방식은 어디에서 문제가 발생할까요?
바로 내가 가진 정보를 어느 특정한 사람에게 보여주기 위해서 암호문과 키를 줄 때 발생합니다. 주는 과정에서 인터넷을 이용할테고 누군가 접근한다면 키를 도난당할 수도 있습니다.그렇다면 이 한계를 비대칭키는 어떻게 해결할까요?
A라는 사람이 공개키를 어디 홈페이지 올립니다.
그러면 이 공개키를 가지고 B라는 사람은 A라는 사람에게 주기 위한 평문을 암호화합니다. 이 암호화된 내용을 평문으로 바꿀 수 있는 키는 A가 가진 비공개키 뿐입니다. 즉 이 암호화된 내용의 평문을 알 수 있는 사람은 A 뿐인거죠. A와 B만이 서로 주고 받은 정보를 알 수 있습니다.
-
비대칭키 혹은 공개키 암호화 기법을 이용해서 전자서명 하는 방법
A라는 사람은 자신의 비공개키를 이용해서 평문을 암호화 합니다.
그리고 평문+암호화된 내용을 B에게 보냅니다. 공개키는 모두가 볼 수 있는 곳에 올려둡니다.B는 평문+암호화된 내용에서 암호화된 내용을 공개키를 이용하여 복호화합니다. 이 복호화된 내용 = 평문 인지 확인하고 같으면 A가 보낸 내용이 조작되지 않았다는 것을 확인할 수 있습니다.
만약 나쁜 의도를 가진 사람인 크래커가 조작된 내용을 B라는 사람에 줬다면 B는 A라는 사람이 올린 공개키를 이용하여 크래커의 암호화된 내용을 복호화하였습니다. 하지만 복호화된 내용 ≠ 평문 이기 때문에 조작된 내용임을 확인할 수 있습니다.
즉 전자서명은 자신의 비공개키를 이용하여 암호화한 내용과 평문을 붙입니다. 이 암호화된 내용 + 평문 그리고 공개키를 공개함으로써 진행됩니다.
HTTPS와 SSL
HTTP가 SSL을 이용한 통신 방법을 HTTPS라고 합니다.
SSL(Secure Socket Layer) ≒ TLS(Transport Layer Security)
SSL이 넷스케이프에 의해 처음 등장했고 이 기술이 국제표준화기관에 이관되면서 TLS로 불리게 되었다고 합니다.
따라서 둘다 같은 말로 사용되며 SSL이 역사가 더 오래된 단어여서 더 통용되었다고 합니다.
HTTPS와 SSL를 이해하기 위해서는 몇 가지 기본 배경이 필요합니다.
그래서 정리해보겠습니다.
-
CA(Certificate Authority)
클라이언트가 접속한 서버가 신뢰할 수 있는 서버임을 보장하는 역할을 전담하는 기관입니다.각자의 브라우저마다 CA를 선정해서 CA 목록을 자사의 리스트에 탑재하고 있습니다.
CA 기관의 예시로는 Symantic, Comodo, GoDaddy, GlobalSign이 있으며 서버는 CA 기관으로부터 SSL 인증서를 구입합니다.
구입할 때는 자신의 사이트가 제공하는 서비스가 신뢰할 수 있는지를 증명할 서류를 보내야합니다. -
CA로부터 구매한 인증서에 포함된 내용
- 서비스의 정보(인증서를 발급한 CA, 서비스의 도메인 등)
- 서버 측 공개키(공개키의 내용, 공개키의 암호화 방법)
-
브라우저는 CA를 알고 있습니다.
브라우저는 어떤 기관이 공인된 기관인지 알고 있습니다.
앞에 말했듯이 브라우저는 CA 리스트를 내장하고 있다고 했습니다.
실제로 디지노타라는 CA가 해킹 공격을 받아 파산했는데 그 때 브라우저 서비스를 제공하는 기관에서는 다지노타를 CA 리스트에서 제거했습니다. -
대칭키와 공개키는 앞서 배웠기 때문에 생략하겠습니다.
SSL 통신과정
SSL 통신할 때 공개키와 대칭키를 혼합해서 사용합니다.
그 이유는 무엇일까요?
공개키는 두 개의 키를 모두 가지고 있어야 해서 컴퓨팅적 비용이 많이 듭니다. 하지만 대칭키의 한계점을 보완합니다. 대칭키는 속도가 빠른 반면에 보안적인 문제가 발생합니다. 따라서 이 둘의 장단점을 상쇄하여 이 둘을 혼합해서 사용합니다.
일단 먼저 큰 그림부터 그리겠습니다.
컴퓨터와 컴퓨터가 네트워크를 이용해서 통신할 때는
악수-> 전송-> 세션 종료 3가지 단계로 진행합니다.
공개키 암호화 방식 악수 단계에서 CA의 전자서명과 대칭키를 안전하게 주고 받기 위해 클라이언트와 서버가 사용합니다
대칭키는 실제로 데이터를 주고 받을 때 사용합니다.
1. 악수 🤝
- 클라이언트가 서버에 접속합니다. 이 단계를 Client Hello라고 합니다.
이 단계에서 주고 받는 정보는 아래와 같습니다.
- 클라이언트 측에서 생성한 랜덤데이터
- 클라이언트가 지원하는 암호화 방식들
- 세션 아이디 : 이미 SSL 핸드쉐이킹을 했다면 비용과 시간을 절약하기 위해서 기존 세션을 재활용하게 되는데 이 때 사용할 연결에 대한 식별자를 서버에 보냅니다.
- 서버는 Client Hello에 대한 응답으로 Server Hello를 합니다.
이 단계에서 주고 받는 정보는 아래와 같습니다.
- 서버 측에서 생성한 랜덤 데이터
- 서버가 선택한 클라이언트의 암호화 방식
- 인증서
-
클라이언트는 서버의 인증서가 CA에 의해서 발급된 것인지 확인하기 위해서 클라이언트에 내장된 CA 리스트를 확인합니다. CA 리스트에 인증서가 없다면 사용자에게 경고메세지를 출력합니다.
사실 이 단계는 위에서 배운 전자서명이 그대로 적용됩니다.
A는 CA이고 B는 웹 브라우저입니다.
서버는 A로부터 인증서를 샀습니다.클라이언트는
2번을 통해 받은 서버의 랜덤 데이터
+ 클라이언트가 생성한 랜덤데이터
= pre master secret라는 키를 생성합니다.이 키는 뒤에서 살펴볼 세션 단계에서 데이터를 주고받을 때 암호화를 위해 사용됩니다. 이 암호화 방식은 대칭키 방식이기 때문에 pre master secret은 외부에 절대 노출해서는 안됩니다. (즉 대칭키를 생성하기 위해서 pre master secret라는 키가 사용되기 때문에 이를 절대 외부에 노출해서는 안된다.)
그렇다면 한 가지 문제가 있습니다.
이 대칭키를 어떻게 서버에 전달할 수 있는가라는 문제가 발생합니다.앞서 인증서에는 서버의 공개키가 포함되어 있다고 했습니다.
이제 그 공개키를 이용할 때입니다.pre master secret + 인증서에 포함된 서버의 공개키
= 암호화해서 서버에 전달서버는 자신의 비공개키를 이용하여 암호화된 내용을 복호화해 pre master secret라는 대칭키를 얻을 수 있습니다.
-
서버는 자신의 비공개키를 이용하여 암호화된 내용을 복호화해 pre master secret라는 대칭키를 얻을 수 있습니다.
이제 서버와 클라이언트 모두 pre master secret라는 대칭키를 가지고 있습니다.
서버와 클라이언트 모두 일련의 과정의 거쳐
pre master secret -> master secret 값으로 만듭니다.master secret -> session key를 생성
이 session key값을 이용해서 서버와 클라이언트는 대칭키 방식으로 암호화를 한 후에 데이터를 주고 받습니다.
session key = 대칭키
-
클라이언트와 서버는 핸드쉐이크 단계 종료를 서로에게 알립니다.
2. 세션 🗞️📰
실제로 서버와 클라이언트가 데이터를 주고 받는 단계입니다.
서로가 모두 대칭키를 가지고 있기 때문에 자신의 내용을 암호화하고
상대의 내용을 복호화할 수 있습니다.
3. 세션 종료
데이터의 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알립니다.
이 때 통신에서 사용한 대칭키인 세션키는 폐기합니다.
정리
정리를 해볼까요
오늘 암호학을 배웠습니다.
암호학에는 단방향과 양방향이 있습니다.
단방향은 복호화를 하지 못하는 암호화만 가능한 알고리즘입니다.
MD5, SHA 등의 방법이 있습니다.
양방향은 복호화와 암호화 모두 가능합니다.
여기서 복화화와 암호화 모두 같은 키를 사용하는 대칭키 방식과
서로 다른 키를 사용하는 비대칭키 혹은 공개키 방식이 있습니다.
대칭키는 대표적으로 AES, 비대칭키는 RSA가 있습니다.
비대칭키는 전자서명에 이용됩니다.
비대칭키는 외부에 공개하는 공개키와
자신만 알고 있는 비공개키가 있습니다.
비공개키를 통해 암호화한 내용 + 원본 그리고 공개키를 공개합니다.
사용자는 공개키를 이용하여 복화화하고 이 내용이 원본과 같으면 조작되지 않았다는 것을 알 수 있습니다.
HTTPS는 HTTP에 SSL을 이용한 통신방법입니다.
서버는 SSL 인증서를 CA 기관에서 구매해야 합니다.
SSL 인증서에는 서버의 공개키가 포함되어 있습니다.
SSL 통신과정에서는 앞서 말한 전자서명 방식이 이용됩니다.
이로써 클라이언트는 서버가 신뢰할만한 사이트인지 악수하는 과정을 거칩니다.
실제로 데이터를 주고받을 때는 대칭키를 이용하는데
대칭키를 서로 공유하기 위해서 대칭키를 암호화해야 합니다.
암호화하는 과정에서 인증서에 포함된 서버의 공개키를 이용해서 암호화합니다.
서버는 이 암호화된 대칭키는 자신의 비공개키를 이용해서 복호화합니다.
이로써 클라이언트와 서브는 session key라는 대칭키를 공유하게 됩니다.
실제로 데이터를 주고받을 때는 자신의 데이터를 대칭키를 이용해서 암호화하고 서로의 데이터를 복호화하여 주고 받습니다.
reference
생활코딩 암호학1
생활코딩 HTTPS와 SSL
https://www.crocus.co.kr/1387
