대칭키 암호화
암호화할 때 쓰는 키와 복호화할 때 쓰는 키가 동일함. 자물쇠 하나에 열쇠도 하나인 셈이라 그 열쇠를 아는 사람만 잠그고 풀 수 있음.
송신자와 수신자가 사전에 같은 비밀키를 공유하고, 송신자는 평문을 그 키로 암호화해서 보내고 수신자는 같은 키로 복호화해서 평문 복원.
속도가 빨라서 대용량 데이터 암호화에 적합하지만, 키를 안전하게 전달하는 것 자체가 문제(키 배송 문제)고 통신 상대가 늘어날수록 관리할 키 개수가 폭증함. 대표 알고리즘은 AES(현재 표준), 과거엔 DES·3DES를 썼지만 지금은 취약해서 거의 안 씀.
예시로는 Wi-Fi 비밀번호로 파일을 암호화하는 ZIP 암호. 나와 친구가 똑같은 비밀번호로 파일을 잠그고 여는 것과 같은 개념.
비대칭키 암호화(공개키 암호화): 암호화용 키(공개키)와 복호화용 키(개인키)가 서로 다르고 한 쌍으로 존재함. 누구나 넣을 수 있지만 주인만 열 수 있는 우체통에 비유할 수 있음. 공개키는 우체통 투입구처럼 모두 공개, 개인키는 우체통 열쇠처럼 본인만 보관.
수신자가 공개키/개인키 한 쌍을 만들고 공개키를 모두에게 공개하면, 송신자는 수신자의 공개키로 암호화해서 보내고 수신자는 자신의 개인키로만 복호화함. 이렇게 하면 대칭키의 키 배송 문제가 해결됨.
단점은 연산이 복잡해서 속도가 느리다는 것. 대표 알고리즘은 RSA가 가장 널리 쓰이고, ECC는 더 짧은 키로 비슷한 안전성을 내서 모바일이나 IoT에서 선호됨.
반대로 개인키로 암호화하고 공개키로 복호화하는 구조를 쓰면 디지털 서명 검증이 가능함. 본인만 가진 개인키로 서명하면 누구나 공개키로 이 사람이 서명한 게 맞는지 확인할 수 있음.
예시: HTTPS 접속 시 서버 공개키로 처음 통신을 암호화하는 부분, 이메일 PGP 암호화.
해시: 임의 길이의 데이터를 고정 길이의 값으로 변환하는 함수. 암호화가 아니라 복호화가 불가능한 단방향 함수라서 원본 복원이 안 됨.
같은 입력이면 항상 같은 출력이 나오고, 입력이 한 글자만 달라져도 출력이 완전히 달라짐(눈사태 효과). 서로 다른 입력이 같은 출력을 낼 확률도 극히 낮음(충돌 저항성).
대표 알고리즘인 MD5·SHA-1은 충돌 취약점이 발견돼서 권장 안 하고, SHA-256·SHA-3가 현재 표준으로 많이 쓰임.
예시: 비밀번호 “1234”를 SHA-256 해시값으로 변환해서 DB에 저장하고, 로그인 시 입력값도 해시해서 비교하는 방식.
솔트: 해시만으로는 부족한 이유는, 같은 비밀번호(“1234”)를 쓰는 사람이 여러 명이면 해시값도 똑같이 나오기 때문. 이 경우 미리 계산해둔 해시값 사전(레인보우 테이블)으로 역추적이 가능해서 취약함.
솔트는 비밀번호를 해싱하기 전에 추가하는 임의의 랜덤 문자열. 사용자마다, 저장할 때마다 다른 솔트값을 부여함.
비밀번호 “1234”에 솔트 “a8f3”을 합쳐서 해싱하고, 저장은 해시값과 솔트값을 함께 보관함. 같은 비밀번호라도 사람마다 솔트가 달라서 결과 해시값이 전부 다르게 나오고, 이 때문에 레인보우 테이블 공격이 무력화됨.
예시: 사용자 A는 “1234”+“x8kd”로 해시값 α, 사용자 B는 “1234”+“9jql”로 해시값 β가 나오는 식. 같은 비밀번호인데 완전히 다른 결과가 나옴.
PKI(공개키 기반구조): 비대칭키 암호화는 이 공개키가 진짜 그 사람 것이 맞는지 보장이 안 됨. 중간자가 가짜 공개키로 바꿔치기할 수 있기 때문. PKI는 공개키의 신원을 보증해주는 전체 시스템.
핵심은 CA(인증기관)라는 신뢰할 수 있는 제3자 기관이 공개키와 신원을 묶어서 인증서 발급.
인증서에는 소유자 정보, 공개키, 유효기간, CA의 전자서명 등이 들어감.
웹사이트가 CA에 인증서 발급을 요청하면 CA가 신원을 확인하고 인증서를 발급하고, 브라우저가 사이트에 접속할 때 이 인증서를 받아서 CA가 신뢰 가능한 기관인지, 위변조는 없는지 검증함. 검증을 통과해야 진짜 그 사이트의 공개키라고 신뢰할 수 있음.
예시: 브라우저 주소창의 자물쇠 아이콘을 클릭했을 때 보이는 인증서 정보. 가짜 은행 사이트는 진짜 은행 명의의 인증서를 발급받을 수 없어서 이 구조로 피싱을 막을 수 있음.
TLS: 인터넷 통신 구간을 암호화하는 프로토콜로 HTTPS의 핵심(HTTP + TLS = HTTPS). 앞에서 다룬 대칭키, 비대칭키, 해시, PKI 개념이 전부 조합돼서 동작함.
핸드셰이크 흐름을 단순화하면, 클라이언트가 서버에 접속을 시도하면서 지원 가능한 암호 방식을 전달하고, 서버가 PKI 기반 인증서를 전달하면 클라이언트가 CA를 통해 이 인증서를 검증함. 검증이 통과되면 클라이언트가 대칭키로 쓸 세션키를 만들어서 서버의 공개키로 암호화해 전달하고, 서버는 자신의 개인키로 복호화해서 세션키를 얻음. 이후 통신은 이 세션키로 대칭키 암호화를 이용해서 진행됨.
대칭키와 비대칭키를 같이 쓰는 이유는, 비대칭키는 처음 세션키를 안전하게 교환하는 데 쓰고(느리지만 키 배송 문제 해결), 대칭키는 실제 대량의 데이터를 주고받는 데 쓰기 때문(빠름). 서로의 단점을 보완하는 하이브리드 구조인 셈.
예시: 브라우저 주소창의 자물쇠 아이콘이 TLS로 암호화된 연결이라는 표시고, 온라인 쇼핑몰 결제 페이지가 https://로 시작하는 이유도 이것.