데이터를 복호화할 수 없는 형태로 암호화하는 방식 - 주로 사용자 비밀번호 / 파일 무결성 검증 / API 인증(전송 중 노출 방지) / 전자 서명에 사용 - 암호화된 비밀번호를 DB에서 탈취해 가도 원본을 알 수 없어 해킹 방어에 상대적으로 유리 - 검증 시에는 입력받은 비밀번호를 똑같이 암호화하여 암호화된 비밀번호끼리 비교 - 유저가 비밀번호를 잃어버리면 되찾을 수 없고, 변경만 가능 - 대표적으로 SHA-256(SHA-2) 암호화 알고리즘이 있음
양방향 암호화
데이터를 암호화한 후 복호화를 통해 원래의 데이터로 되돌릴 수 있는 암호화 방식 - 암호화 후 클라이언트와 서버 모두 암호화 결과를 복호화할 수 있는 방법을 가지고 있는 방식 - 주로 DB, 파일 암호화 / 네트워크 데이터 전송(HTTPS) / 전자서명 / 보안채널 생성 등에 사용 - 주로 데이터를 안전하게 저장하거나 전송할 때 사용
단방향 암호화의 필요성
1. 비밀번호 보호 비밀번호는 저장소에 평문(plain text)으로 저장되면 노출 시 치명적임 단방향 암호화를 사용하면 데이터가 노출되더라도 복호화할 수 없기 때문에 공격자가 원래 비밀번호를 알 수 없음
2. 데이터 무결성 검증 동일한 입력값에 대해 항상 동일한 암호화 결과를 반환하므로 데이터의 변경 여부를 확인할 수 있음 예: 파일 무결성을 검증할 때 해시값을 사용
3. 보안성 강화 해커가 데이터베이스에 접근하더라도 해시된 값만 볼 수 있음 주요 데이터가 평문으로 노출되지 않아 원문 보호 가능
양방향 암호화의 필요성
1. 데이터의 가독성 유지 민감한 데이터를 암호화해 저장하되, 필요 시 원본 데이터로 복호화해 사용할 수 있어야 함 예: 신용카드 정보, 개인 식별번호 등
2. 안전한 데이터 전송 데이터가 네트워크를 통해 전송될 때 중간에서 노출되더라도 복호화 키가 없다면 해독할 수 없게 함
3. 시스템 통합 및 인증 특정 시스템이나 서비스와의 연동 시 데이터를 암호화해서 보내고, 받은 측에서 이를 복호화하여 원본 데이터를 확인
4. 데이터 보호 및 접근 제어 비밀번호처럼 복호화할 필요는 없지만, 다른 민감한 정보(예: 주소, 은행 계좌) > 양방향 암호화로 관리
각 암호화의 종류
방식
종류
설명
단방향 암호화
해시 함수
입력 데이터를 고정된 길이의 해시값으로 변환 - SHA(Secure Hash Algorithm): SHA-256, SHA-512 등 - Bcrypt: 비밀번호 암호화에 최적화, 속도가 느려 무차별 대입공격(Brute-force) 방지 - Argon2: 최신 비밀번호 암호화 알고리즘으로 높은 보안성 - MD5: 빠르지만 보안성이 낮음. 보안성이 낮아도 빠른 처리가 요구되는 경우 사용
솔트 & 페퍼
단순 해시만 사용하면 동일 비밀번호에 대해 동일한 해시값이 생성되므로 이를 방지하기 위해 사용 - 솔트(Salt): 해시값 생성 시 랜덤 데이터 추가 - 페퍼(Pepper): 시스템 전반에 걸쳐 동일한 비밀키를 해시값에 추가
양방향 암호화
대칭키 암호화
암호화와 복호화에 동일 키 사용 - 빠른 암호화/복호화 속도 - 키가 노출되면 보안 위험 > 키 관리가 중요 - AES(Advanced Encryption Standard): 가장 널리 사용, 속도/보안성 모두 우수 - Triple DES(3DES): DES를 3번 반복하는 방식으로 보안 강화했으나 속도 느림 - DES: 오래되고 보안성이 낮아 현재 권장x
비대칭키 암호화
공개키(Public Key)와 개인키(Private Key) - 서로 다른 2가지 키를 사용 - 공개키: 데이터 암호화 키, 누구나 접근 가능 - 개인키: 데이터 복호화 키, 비밀리에 관리 - 키 공유 시 안전, 한쪽 키를 노출해도 다른 키 없이 복호화 불가능 - 대칭키보다 속도 느림 - RSA(Rivest-Shamir-Adleman): 가장 널리 사용 - ECC(Elliptic Curve Cryptography): RSA보다 짧은 키 길이로 높은 보안성 제공
키(Key)의 저장
1. 양방향 암호화 1-1. 대칭키 암호화 키 관리 가장 중요 - 키 노출 시 데이터 보호 불가능 - 키 관리 시스템(KMS): AWS KMS, Azure Key Vault 등을 통해 안전하게 저장 및 관리 - 환경변수 또는 서버 내 안전한 파일: 안전한 접근 권한 설정 필수
1-2. 비대칭키 암호화 공개키는 공개 가능, 개인키는 반드시 안전하게 저장 - KMS(대칭키와 동일) - HSM(Hardware Security Module)와 같은 보안 장치 - 애플리케이션의 보안된 저장소
2. 단방향 암호화 복호화가 필요하지 않음 > 비밀키 필요 X 솔트(Salt)와 같은 랜덤값은 안전하게 저장 필요 - 솔트: 보통 DB에 함께 저장하나 비밀번호와 별도로 관리 - 페퍼: 애플리케이션 서버나 환경 변수에 저장되며 DB에 저장하지 않음
SSL과 레이어
개념
설명
SSL
SSL (Secure Sockets Layer) - 데이터를 암호화해 안전한 통신을 보장하는 프로토콜(암호 규약) - 현재는 TLS (Transport Layer Security)가 사용되나 이를 관습적으로 SSL이라고도 부름 - OSI 7계층 중, 6번째 표현 계층에서 데이터를 암호화 및 복호화 - SSL 인증서가 있는 서버는 서버에 접속한 클라이언트에게 인증서를 전달, 신뢰성 확보 - 전달되는 내용의 악의적 변경 방지 및 전달되는 내용 노출 방
HTTP
HTTP (HyperText Transfer Protocol) - 웹에서 클라이언트와 서버 간에 데이터를 주고받기 위한 규칙(프로토콜) - 주로 웹 페이지, 이미지, 비디오 등 리소스 전송에 사용
HTTPS
HTTPS (HyperText Transfer Protocol Secure) - HTTP에 SSL/TLS를 추가하여 데이터를 암호화한 보안 버전의 HTTP - SSL/TLS를 통해 HTTP 요청과 응답 데이터를 암호화 - OSI 7계층 중, 7번째 응용 계층에서 HTTP 프로토콜에 SSL/TLS 결합 - 한편, SSL/TLS는 4번째 전송 계층에서 동작하는 TCP 기반으로 동작 - 통신의 보안성 강화
SSL의 동작 과정
2차 출처: Certificate pinning technique on iOS ❘ by Anderson Santos Gusmão ❘ Medium (https://andersongusmao.medium.com/certificate-pinning-technique-on-ios-af0f0813e88)
악수 > 전송 > 세션 종료로 이어지는 컴퓨터와 컴퓨터 간 네트워크 통신 과정을 핸드쉐이크라고 부른다. SSL 또한 웹서버와 웹브라우저의 통신 과정이므로 SSL 핸드쉐이크 과정을 거치는데, 공개키와 대칭키가 혼합된 형식이다. 대칭키는 보안 문제가, 공개키는 자원 사용의 증가 문제가 있기 때문에 둘의 장점만 결합해서 사용함.
1. 클라이언트: Hello 나 접속했어. 난 암호화 방식 이거이거 가능한데 협상하자. 나중에 이 과정 생략하려면 연결에 대한 세션ID(연결에 대한 식별자)도 같이 줄게. 일단 키 생성용 랜덤 바이트 문자열도 보낸다.
2. SSL 서버: Hello, 어서와. 암호화 방식은 니가 보낸 거중에 이걸로 하자. 협상 끝. 이거 내 SSL 인증서야. 공개키가 포함돼 있어. 내쪽에서 만든 키 생성용 랜덤 바이트 문자열도 보낼게 키 맞추자.
2-2. SSL 서버: (SSL 서버에서 요구 시에만) 너도 클라이언트 인증서 줘. (이후 과정은 클라이언트가 인증서를 보내고 동일하게 서버측에서 아래 방식을 거쳐 검증함.)
3. 클라이언트: 내장 CA(Certificate Authority, 공인인증기관) 리스트에서 니가 보내준 SSL 인증서 발급한 기관 찾아서 검증했어. (검증은 어떻게 했냐면, 일단 그 기관 인증서가 내장 CA 리스트에 있는지를 먼저 찾았어. 찾은 인증서에 해당기관이 제공한 공개키도 같이 내장돼 있는데, 그걸로 네가 보낸 인증서 복호화했어. 잘 되는 거 보니 이 기관 개인키로 암호화한 인증서 맞고 진짜더라) 인증서에 명시된 서버도 맞고, 답변 준 이 서버가 실제 이 도메인 소유자도 맞네. 믿어도 되겠다.
4. 클라이언트: 우리 둘이 방금 주고받은 키 생성용 랜덤 바이트 문자열 조합해서 Premaster secret 값을 만들었어. 네가 보낸 인증서에 포함된 공개키로 이 premaster secret 값을 암호화해서 보낼게. 이게 클라이언트 키, 즉 비공개 키야.
5. SSL 서버: 니가 보낸 Premaster secret 값 암호화한 거 잘 받았어, 내가 보냈던 인증서 공개키에 매칭되는 비밀키로 복호화했어. 이제 우리 같은 Premaster secret 값을 공유하게 됐네.
6. 클라이언트: 세션이 만들어졌네. 그럼 양쪽에서 접속 시 주고받은 키 생성용 랜덤 바이트 문자열 각 1개씩과 우리끼리만 알고 있는 premaster secret까지, 총 3가지를 사용해서 세션 키를 생성할게. 이게 바로 우리가 사용할 대칭키야! finished < 이거 세션 키를 통해 암호화해서 보낸다.
7. SSL 서버: 나도 5번과정 똑같이 할게. finished.
7. 클라이언트, SSL 서버: 핸드쉐이크 끝! 세션 키(대칭)로 이제 메시지 주고받자. 데이터 전송 끝나면 세션 키는 폐기하면 돼.
SSL의 계층
출처: IoT Security with SSL/TLS in MicroPython ❘ Blog of Ken W. Alger (https://www.kenwalger.com/blog/iot/iot-security-ssltls/)
그렇다면 SSL은 위에서 어느 계층이라고 할 수 있을까? OSI 7계층 모델에서 SSL이 동작하는 계층은 어느 한 계층이라고 할 수 없다. 일반적으로 전송 계층에 해당한다고 설명되지만, 실제로는 웹서버와 웹브라우저 사이의 프로토콜로서 동작하기 때문이다. 위 표를 보면 OSI 모델에서는 표현 계층, TCP/IP 모델에서는 응용 계층에서 동작한다고 표현되어 있지만, 실제로는 그렇게 간단하게 특정 계층을 지목할 수 없다.
SSL은 HTTP 등 응용 계층 프로토콜과 함께 사용되어 데이터를 암호화하고 인증하는 역할을 한다. 그러나 한편, TCP/IP와 같은 전송 계층 프로토콜을 통해서 데이터를 전송하며, 신뢰성을 추구하기 위해 전송 계층을 활용하므로 일반적인 응용 계층의 특성과는 다르게 동작하는 부분이 있다. 게다가, 전송/응용 계층뿐만 아니라 SSL의 결과값으로 나오는 세션 키를 통해 보안 세션을 설정하고 핸드쉐이크를 수행한다. SSL의 특징인 데이터 무결성은 전송 계층의 TCP 프로토콜과 밀접하게 연관되지만, 세션 계층에서 설정된 보안 세션을 기반으로 암호화가 진행되며, HTTP와 SSL이 결합한 HTTPS는 전송도 세션도 아닌 응용 계층 프로토콜로 주로 분류된다. 즉, SSL은 네트워크 모델에서 다양한 계층을 거쳐 작동하게 된다.
∴ 그러므로, 굳이 특정 계층을 명시해야 한다면 SSL은 명확히 한 계층이 아닌, 응용 계층~세션 계층~전송 계층 사이의 서브 레이어에 위치한다고 할 수 있다.
