-
암호의 원리를 알아보자! 이고잉님의 암호법 강의 후기Knowledge/Security 2019. 12. 10. 03:06반응형
이고잉님이 홍대에 위치한 릴리쿰 스테이지에서 암호 관련 강의를 하신다는 메일을 받았습니다. 평소 한번 뵙고 싶기도 했고 면접시에 http와 https에 관한 질문을 받았을 때 명확히 설명하지 못한 적이 있는데 이 역시 암호의 원리에 기반한 것이란 설명에도 마음이 동해 알람까지 맞춰놓고 기다리다 참가 신청을 했고, 다행히 참석할 수 있게 되어 12월 5일 목요일 릴리쿰 스테이지에 다녀왔습니다. 그 날 세시간 동안 배운 내용을 포스팅하며 정리해보겠습니다.
- 암호법이란?
암호법은 영어로 Cryptography라고 합니다. 이 단어는 '비밀'을 뜻하는 Crypto와 '다루는 방법을' 뜻하는 Graphy로 나눌 수 있습니다. 즉 암호법이란 비밀을 다루는 방법을 뜻합니다.
- 암호에서 중요한 것들
암호에서 중요한 건 세가지입니다.
1. 기밀성 : 송신자와 수신자만이 메시지 내용을 알 수 있게 해야 하고
2. 무결성 : 정보가 전송 도중에 변경되지 않도록 해야하며
3. 인증 : 보낸 사람이 틀림없이 송신자와 같은 사람임을 증명해야 합니다.
이를 확보하기 위해 과거엔 암호화 알고리즘을 숨기는 방법을 택했지만
정보화 사회로 접어든 현대 사회에선 암호화 알고리즘을 공개하는 대신 key를 활용하는 방법을 사용합니다.
이를 이해하기 위해선 먼저 암호의 기본 원리에 대해 이해할 필요가 있습니다.
먼저 '암호화'와 '복호화'의 의미에 대해 알아보겠습니다.
- 암호화(encryption) 와 복호화(decryption)
- 암호화
말 그대로입니다. 평문을 암호 알고리즘을 통해 암호로 바꾸는 것을 암호화라고 합니다.
Plain Text (평문) -> cryptography algorithm 선택 -> cipher text (암호문)
- 복호화
반대로 암호문을 암호 알고리즘을 통해 평문으로 바꾸는 것을 복호화라고 합니다
Cipher text (암호문) -> cryptography algorithm 선택 -> Plain Text (평문)
- 암호법 카테고리
암호법은 암호화만 가능한 단방향 암호화와 암호화와 복호화가 모두 가능한 양방향 암호화로 나눌 수 있습니다.
- 단방향 암호화
암호화만 가능한 단방향 암호화의 대표적인 알고리즘으로는 Hash 알고리즘이 있습니다. Hash는 원래 '다진 고기'를 의미하는 단어로 다진 고기는 다시 원래대로 되돌리지 못하는 것처럼 Hashing한 암호는 원래 값으로 되돌릴 수 없기에 이에 대한 비유로 붙은 이름으로 추정됩니다. 그럼 암호화만 가능한 이런 방식을 어떤 때 사용할까요?
그 특성 때문에 메시지나 파일의 무결성을 확인할 때 유용합니다. 예시를 하나 보겠습니다. 널리 알려진 WAS인 tomcat의 다운로드 페이지에 가보면 다운로드 받을 파일 형식을 선택하는 링크 옆에 hash 알고리즘 중 하나인 sha512 란 글자가 적혀있고 링크가 걸려있는 걸 확인할 수 있습니다.
클릭해보면
이런 정체를 알 수 없는 문자가 나오죠. 뭘까요? 비밀은 아래에서 확인할 수 있습니다. 파일을 다운로드 받고 File의 Hash값을 확인할 수 있는 사이트에 접속해 다운로드 받은 압축 파일을 드래그 해 넣어보면
tomcat 다운로드 페이지에서 확인할 수 있었던 정체를 알 수 없는 문자열과 같은 문자열이 출력되는 걸 확인할 수 있습니다. 즉 원문이 같고 똑같은 hash 알고리즘을 사용한다면 출력되는 hash 값은 어디서 확인하든 같다는 점을 활용해서 유저가 다운로드 받은 파일의 무결성을 확인할 수 있도록 톰캣측에서 hash 값을 제공해 준 것이고 유저들은 이걸 활용해 무결성 체크를 할 수 있는 것이죠.
이처럼 '무결성 확인'이란 목적을 달성하기 위해선 굳이 복호화는 필요하지 않으니 이런 경우 hash 알고리즘이 유용하게 사용됩니다. 거기다 복호화가 되지 않기 때문에 원형을 알 수 없다는 점에서 웹/앱 서비스에서 유저의 비밀번호를 저장할 때도 hash가 유용하게 사용되는데 단순히 hash 값으로 저장하기만 하는 경우 '원문이 같다면 hash값도 같다'는 점 때문에 인식 가능성이 생길 수 있어 몇 가지 추가 조치가 취해집니다. 이는 본 포스팅의 범위를 벗어나고 이미 좋은 포스팅이 있으니 이 부분은 링크로 남기겠습니다. ( 안전한 패스워드 저장 )
유의할 점 하나만 덧붙이자면 Hash 기법 중에는 SHA-256 또는 SHA- 512 알고리즘을 쓰는 것이 좋습니다. 이전엔 안전했던 hash 기법인 MD-5 의 경우도 컴퓨팅 파워가 발전함에 따라 공격 가능성이 증명되었고, 컴퓨팅 파워는 무서운 속도로 계속 발전하고 있으니 길이가 길어 더욱 안전한 hash 기법을 선택해서 나쁠 건 없겠죠?
- 양방향 암호화
암호화와 복호화가 가능한 양방향 암호화는 대체로 Key가 필요합니다. 이는 다시 대칭키 방식과 비대칭키 방식으로 나눌 수 있습니다.
- 대칭키 방식
암호화 할 때와 복호화 할 때의 키가 같은 방식입니다. 대칭키 방식의 대표적인 알고리즘으로는 AES가 있습니다.
CyberChef를 활용해 해보자면
Hello Secret !! 이란 평문을 1234567812345678 ( 16자리여야 합니다 ) 이란 키를 활용해 암호화 한 후
동일한 key를 활용해 복호화하니 Hello Secret!! 이란 원래의 평문이 나타나는 걸 확인할 수 있습니다
이 방식은 비대칭키 방식에 비하면 속도가 빠릅니다. 그러나 암호화에 사용한 대칭키로 복호화를 해야 하기 때문에 암호문과 대칭키를 함께 전달해야 한다는 문제가 있습니다. 탈취라도 당하면 암호가 노출될 위험이 있겠죠.
- 비대칭키 방식
비대칭키 방식의 대표적인 알고리즘은 RSA가 있습니다. ( RSA 방식은 Online RSA에서 실습해 볼 수 있습니다. ) RSA 방식에선 private key하나와 public key 하나 이렇게 세상에서 유일한 한 쌍의 키가 생성됩니다. 하나의 키가 암호화를 담당하면 다른 하나의 키가 복호화를 담당하는 방식으로 작동하죠. 무엇이 암호화를 담당하고 복호화를 담당하는지는 목적에 따라 달라집니다.
- B가 A에게 비밀 메세지를 보내는 경우
- A가 private key와 public key를 생성합니다.
- A의 public key를 공개 영역을 거쳐 B에게 전송합니다.
- B가 A에게 전송하고자 하는 비밀 메세지를 A의 public key로 암호화 합니다.
- 그렇게 생성한 B의 암호문을 공개 영역을 거쳐 A에게 다시 전송합니다.
- 도착한 B의 암호문을 A가 가지고 있는 pirvate key로 복호화하여 내용을 확인합니다.
이 방식을 활용하면 B의 메세지는 A의 public key로 암호화 되었기에 A의 private key로만 복호화 할 수 있는데 A의 private key는 공개 영역에 노출될 일이 없기 때문에 기밀성을 유지할 수 있습니다.
- A가 B에게 메세지를 보낼 때 이것이 A가 발송한 것이란 서명을 검증하기 위해 사용하는 경우
- A가 private key와 public key를 생성합니다.
- A가 public key를 공개해서 B에게 전달합니다.
- A가 평문을 private key로 암호화해서 암호문(서명)을 생성합니다.
- 생성한 암호문(서명)을 발송하는 평문 뒤에 붙이고 공개영역을 거쳐 B에게 전달합니다.
- B는 먼저 받아둔 A의 public key로 평문 뒤에 붙어 함께 온 A의 암호문(서명)을 복호화 합니다.
- A의 public key로 복호화가 된다면 이는 곧 A의 private key로 암호화를 한 암호문(서명)이란 뜻이니 이 서명이 A의 것임을 검증할 수 있습니다.
이렇게 비대칭키 방식을 활용하면 암호에서 중요한 것들을 지키며 비밀 메세지를 보내거나 서명을 검증 할 수 있습니다. 그러나 비대칭키는 느리고 비싸다는 단점이 있습니다.
- PKI ( Public Key Infrastructure ) - 공개키 기반 구조
위에서 보았듯이 대칭키와 비대칭키 모두 장단점이 있습니다. 이 중 단점을 보완하고 장점만을 취하기 위해 현실에서의 암호 통신은 공개키 기반 구조로 이루어집니다. 이 과정은 모두 위에서 정리한 Hash, 대칭키, 비대칭키의 개념을 활용해 이루어 집니다. 현실 세계에서 사용되는 방법이니만큼 서버와 클라이언트 구조로 예를 들어보겠습니다.
- 통신 ( ex. https )
- 서버가 private key와 public key를 만들어서 public key만 공개영역에 공개합니다.
- 클라이언트는 대칭키를 생성하고 공개영역에 있는 서버의 public key를 전달받습니다. 이후 전달받은 public key로 대칭키를 암호화하여 서버에 전달합니다.
- 서버는 전달받은 클라이언트의 암호화된 대칭키를 private key로 복호화합니다.
- 이러면 서버와 클라이언트 모두 같은 대칭키를 가지게 됩니다.
- 이를 바탕으로 서버와 클라이언트는 빠르게 통신할 수 있습니다.
- 서명 검증
- 서버가 private key와 public key를 만들어서 public key만 공개영역에 공개합니다.
- 클라이언트는 공개영역에 있는 서버의 public key를 전달받습니다.
- 서버는 보내려는 평문을 해싱하여 서명을 만들고 그걸 private key로 암호화해서 클라이언트에 전달합니다.
- 클라이언트는 서버의 공개키로 서명을 복호화합니다.
- 그렇게 얻은 hash값과 평문을 해싱한 값이 같은지를 비교하는 방식으로 서명을 검증할 수 있습니다.
위 두 방식 모두 서버가 public key를 공개영역에 공개하면 클라이언트가 그 public key를 전달받아 이후의 과정이 진행됩니다. 그렇다면 public key는 과연 어떻게 전달되는 걸까요? 바로 CA를 통해서입니다
- CA(Certificate Authority)
CA는 공인 인증 기관입니다. 이 공인 인증 기관은 클라이언트가 해당 기관에서 관리하는 서버에 접속시 클라이언트에게 인증서를 보내주는데 이 인증서 안에 서버의 공개키가 포함되어 있습니다. 이 포스팅을 올린 tistory처럼 https로 연결되어 있는 사이트에선 이를 직접 확인할 수도 있습니다. 주소창 옆에 자물쇠 버튼을 클릭하면
인증서란 항목을 볼 수 있습니다. 클릭해서 '자세히' 탭을 열어보면
이처럼 인증서 내부에 공개 키 목록이 있는 걸 확인할 수 있습니다.
- 신뢰 사슬 ( Chain of trust )
그런데 이 인증 기관을 우리가 어떻게 신뢰할 수 있을까요? 이는 인증 경로 탭에서 확인할 수 있습니다.
인증 경로 탭을 눌러보면 이렇게 연결된 형태의 인증서들을 볼 수 있습니다. ( 연결 형태는 사이트마다 상이합니다 )
일단 *.tistory.com 상위의 Thawte TLS RSA CA G1을 열어봅시다. 열어보면
발급자와 발급 대상을 확인할 수 있습니다. 인증 경로 사진과 번갈아 보시면 발급자가 발급 대상의 상위 인증 기관인 걸 확인할 수 있습니다. 즉 Tistory는 Thawte ... 가 인증하고 Thawte..는 DigiCert 가 인증하고 이는 다시 VeriSign이 인증하는 형태입니다. 그럼 VeriSign은 무슨 인증 기관이 인증하고 있을까요? 클릭해보면
VeriSign이 VeriSign을 셀프 인증하고 있는 모습을 볼 수 있습니다. 이런 셀프 인증 기관을 어떻게 믿냐 하실 수도 있지만 걱정하실 필요 없습니다. 이렇게 셀프 인증할 수 있는 Root CA는 전 세계에 몇 군데 없어 이들의 공개키는 브라우저 개발 당시 코드 자체에 저장되는, 신뢰할 만한 것이기 때문입니다.
접속한 웹 서비스를 인증하고 있는 기관부터 이런 Root CA까지의 연결을 신뢰 사슬이라고 합니다. 우리는 이와 같은 신뢰 사슬을 바탕으로 공개키 기반 구조를 활용해 웹상에서 보다 안전하게 통신하고 있는 것입니다.
ps. 당시 이고잉님께서는 pgp와 gpg에 대한 설명도 간단히 해주셨는데 제 이해가 부족해 포스팅으로 정리하기가 애매하네요. 궁금하신 분은 검색해보시길 권합니다! 또한 최대한 오류가 없도록 노력하긴 했지만 앞서 적었듯이 당시 수업 내용을 제 부족한 이해력으로 소화해 포스팅한 내용이라 오류가 있을 수도 있습니다. 틀린 부분이 있다면 댓글로 알려주세요!
참고 :
반응형