| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
- private-access-to-photos
- RN업데이트
- axios
- ios
- rn
- Swift
- debounce
- react-native-image-picker
- react
- Promise
- React-Native업데이트
- Hash-table
- promise.all
- RN새로운아키텍쳐
- react-native
- 비동기
- javascript
- hydration mismatch
- react-native-permissions
- CS
- Throttle
- react native
- named type
- async
- RN아키텍쳐
- react animation
- await
- animation
- motion.div
- no-permission-handler-detected
- Today
- Total
하루살이 개발일지
[CS] 대칭키와 공개키(비대칭키)의 차이점에 대해서 본문
개요
대칭키와 공개키는 널리 사용되는 기본적인 암호화 방법이다.
두 방식은 각각의 특성과 장단점을 가지고 있어서 상황에 따라 적절하게 선택해 사용할 수 있다.
대칭키 암호화
대칭키 암호화는 하나의 키를 암호화와 복호화에 동시에 사용하며, 해당 키를 아는 사람만이 문서를 복호화해 볼 수 있다.
장점 : 공개키 암호화 방식보다 암호화/복호화 과정이 빠르고, 기술적으로 단순하며, 대량의 데이터를 신속하게 처리할 수 있다.
단점 : 키를 교환해야 한다는 문제 (키 배송 문제)가 발생한다. 키를 교환하는 중 키의 분실이나 노출이 데이터의 보안을 위협할 수 있고, 사람이 증가할수록 전부 따로따로 키 교환을 해야하기 때문에 관리해야 할 키가 많아진다.

사용자 A가 암호화된 데이터를 전송하고, 사용자 B가 그 데이터를 복호화하는 과정이다.
여기서 포인트는 두 사용자가 데이터 암호화와 복호화에 동일한 키를 사용한다는 것이다. 이 키는 안전하게 전달되어야 하며, 데이터는 암호화되어 안전하게 사용자 B에게 전달된다. 사용자 B는 동일한 키를 사용해 수신된 데이터를 원래의 형태로 복호화한다. 이 방식은 키 관리가 중요하고, 키의 안전한 전송과 보관이 보안 유지에 핵심이다.
키 배송 문제의 해결방법
대칭키 암호화에서는 같은 키를 암호화/복호화에 모두 사용하기 때문에, 키를 양쪽 당사자가 모두 안전하게 공유해야 한다. 이 과정에서 발생할 수 있는 보안 취약점(ex. 키 누출, 키 도난)이 키 배송 문제이다. 이러한 문제는 통신의 보안을 위협할 수 있다.
이를 해결하기 위해 다양한 방법이 개발되었는데, 키의 사전 공유 / 키 배포 센터에 의한 해결 / Diffie-Hellman 키 교환 / 공개키 암호에 의한 해결 등이 있다.
1. 키의 사전 공유
통신 전에 안전하게 키를 미리 공유하는 방식이다. 사전 만남이나 물리적 수단(ex. 안전한 운송 서비스) 등을 통해 직접 키를 교환할 수 있다. 간단하지만 사람이 많으면 비효율적일 수 있다.
2. 키 배포센터에 의한 해결
키 배포센터(KDC)는 중앙집중식 키 관리 시스템이다. 각 사용자는 초기에 KDC와 자신만의 비밀키를 공유한다. 이후 사용자가 서로 통신하고자 할 때, 두 사용자는 KDC에 접속해 세션 키를 요청한다. 이때 KDC는 두 사용자의 신원을 확인하고 새로운 세션 키를 생성해 두 사용자에게 안전하게 제공한다(세션 키는 통신 세션 동안만 유효하다). KDC는 이 과정에서 사용자의 신원을 보증하고 세션 키의 안전한 전달을 책임진다. 이는 중앙 집중적 관리를 통해 키 배포의 복잡성을 줄여준다.
3. Diffie-Hellman 키 교환
Diffie-Hellman 키 교환은 두 사용자가 사전에 공유된 키가 없어도 각자의 개인키(비밀키)와 공개키를 이용해 안전하게 공통의 비밀키를 생성하는 방식이다. 이를 바탕으로 참가자들은 안전하지 않은 통신 채널에서도 정보를 교환하고, 각자 비밀키를 생성해 암호화된 통신을 수행할 수 있다. 이 방식은 중간자 공격에 취약할 수 있는 단점이 있다.
Diffie-Hellman 에 대한 부가설명
📌 기본 원리
1. 개인키와 공개키 생성 : 각 참가자는 개인키를 생성하고, 이를 바탕으로 계산된 공개키를 상대방과 공유한다.
2. 공유 비밀 키 생성 : 각 참가자는 상대방의 공개키와 자신의 개인키를 사용해 비밀 키를 계산한다. 이 계산은 두 참가자가 동일한 결과를 얻도록 설계되어 있고, 결과적으로 두 참가자는 동일한 비밀 키를 가지게 된다.
📌 안전성 문제
이 방식은 중간자 공격에 취약한데, 그 이유는 통신 과정에서 교환되는 키가 암호화되지 않기 때문이다.
중간자가 통신을 가로채 공개키를 대체할 경우, 중간자는 각 사용자와 별도의 키 교환을 하게 되고, 결과적으로 두 사용자가 서로 다른 키를 사용하게 만들 수 있다. 이렇게 되면 중간자는 통신 내용을 해독하고 조작할 수 있다.
4. 공개키 암호에 의한 해결
아래에서 설명하겠다.
대표 알고리즘
DES, 3DES, AES, SEED, ARIA 등이 있다.
대표 알고리즘 부가 설명
1. DES (Data Encryption Standard) : 56비트 키를 사용하는 대칭키 암호 알고리즘. 현재는 잘 사용되지 않음
2. 3DES : DES의 개선된 버전. 데이터를 세 번 암호화해 보안성을 향상시킴
3. AES (Advanced Encryption Standard) : DES 대체하기 위한 알고리즘. 128비트, 192비트, 256비트의 키 길이를 지원하는 현대적 암호화 알고리즘. 현재 가장 널리 사용됨.
4. SEED : 한국에서 개발된 128비트 키를 사용하는 대칭키 암호 알고리즘
5. ARIA : 한국에서 개발된 또다른 대칭키 암호 알고리즘. 128비트, 192비트, 256비트 키 길이를 지원
공개키 (비대칭키) 암호화
공개키 (비대칭키) 암호화는 대칭키 암호의 취약점을 해결하고자 개발된 암호화 방식이다.
공개키 암호화에서는 한 쌍의 키가 존재한다. 하나는 특정 사람만이 가지는 개인키(또는 비밀키) 이고, 다른 하나는 누구나 접근할 수 있는 공개키이다.
일반적으로 공개키로 데이터를 암호화하면 해당 데이터는 그 쌍이 되는 개인키로만 데이터를 복호화할 수 있다. 반대로 개인키로 데이터에 서명을 하면, 해당 서명은 공개키를 통해 검증될 수 있다. 이처럼 암호화할 때 사용되는 암호키와 복호화할 떄 사용되는 암호키가 서로 다르기 때문에 이를 비대칭키 암호라고도 한다. 공개키 암호화는 복잡한 수학 연산을 수행하기 때문에 대칭키에 비해 속도가 느리다.
장점 : 키의 안전한 전송이 필요없다. 사용자는 공개키를 자유롭게 공유할 수 있으며, 개인키를 안전하게 보관하면 된다.
단점 : 대칭키 방식에 비해 암호화, 복호화 과정이 느리다. -> 속도가 중요한 대량 데이터 처리에는 적합하지 않을 수 있다.

두 사용자 Alice(수신자)와 Bob(발신자)이 안전하게 데이터(이 경우 'Hello Alice' 라는 메시지)를 교환하기 위해 공개키 암호화 시스템을 사용하는 과정이다.
1. 암호화 과정
그림에서는 녹색 열쇠(=공개키)를 사용해 메시지를 암호화한다. 이는 Bob이 Alice의 공개키를 사용해 메시지를 암호화하는 것을 의미한다. 결과적으로 암호화된 데이터 '6EB.....' 가 생성된다.
2. 암호화된 데이터
암호화된 데이터는 안전하게 Alice에게 전달된다. 이 데이터는 Alice의 공개키로 암호화되었기 때문에 Alice의 개인키 없이는 누구도 데이터를 복호화할 수 없다.
3. 복호화 과정
Alice는 빨간 열쇠(=개인키)를 사용해 데이터를 복호화한다. 이는 Alice만의 개인키이며 이 키를 통해 데이터를 원래의 메시지로 복호화할 수 있다.
이 방식에서는 만약 전송 도중 Alice(수신자)의 공개키를 누군가 얻는다고 해도, Alice의 개인키로만 복호화가 가능하기 때문에 기밀성이 있다. 또한 개인키를 가지고 있는 Alice(수신자)만이 암호화된 데이터를 복호화할 수 있으므로 일종의 인증 기능도 제공한다.
인증기관과 인증서
공개키 암호화 과정에는 인증서와 인증기관이 중요한 역할을 한다. 인증기관(Certificate Authority, CA)은 신뢰할 수 있는 제삼자 기관으로, 사용자들의 공개키를 검증하고 인증서를 발급한다. 이 인증서는 사용자의 공개키뿐만 아니라 사용자의 신원 정보를 포함하고 있으며, 인증기관의 디지털 서명으로 보호된다.
통신을 시작하기 전에, 참가자들은 서로의 인증서를 교환한다. 이 과정을 통해 각 참가자는 상대방의 공개키가 실제 그 사람의 것이며, 조작되지 않았음을 확인할 수 있다. 인증서를 통한 이 초기 검증 단계는 공개키의 진위를 확인하고, 통신의 신뢰성을 보장하는 데 필수적이다.
이와 같이 인증서를 사용하는 것은 공개키 인프라(PKI)의 핵심 부분이며, 디지털 세계에서 신원을 보증하고 안전한 정보 교환을 가능하게 한다.
대부분의 경우 대칭키 암호화의 효율성과 공개키 암호화의 보안성을 결합한 하이브리드 암호화 방법이 사용된다. 이 방식에서는 용량이 큰 정보를 대칭키로 암호화하고, 그 대칭키를 다시 공개키로 암호화하여 수신자에게 안전하게 전달한다.

Reference
https://brownbears.tistory.com/332
https://liveyourit.tistory.com/183
https://ko.wikipedia.org/wiki/%EA%B3%B5%EA%B0%9C_%ED%82%A4_%EC%95%94%ED%98%B8_%EB%B0%A9%EC%8B%9D
'CS' 카테고리의 다른 글
| [Network] SSL/TLS에 대하여 (0) | 2024.05.12 |
|---|---|
| [CS] 네트워크에 대하여 (1) | 2024.05.01 |
| OSI 7계층과 TCP/IP 4계층에 대해서 (0) | 2024.04.02 |
| [Data Structure] 기본적인 자료구조 8가지 정리 (2) | 2024.03.22 |
| [CS] HTTP와 프로토콜에 대하여 (response, request) (0) | 2023.07.04 |