"디피-헬만 키교환"의 두 판 사이의 차이
1번째 줄: | 1번째 줄: | ||
''' 디피-헬만 키 교환 ''' | ''' 디피-헬만 키 교환 ''' | ||
− | (Diffie-Hellman Key Exchange) 는 암호 키를 교환하는 방법으로, 디피-헬만 키 교환은 [[RSA]]와 마찬가지로 | + | (Diffie-Hellman Key Exchange) 는 암호 키를 교환하는 방법으로, 디피-헬만 키 교환은 [[RSA]]와 마찬가지로 두 사람이 암호화 되지 않은 통신망을 통해 공통적인 비밀 키를 공유할 수 있도록 하는 것이다. 하지만 이 비밀키가 암호화 되어 통신망에서 지나가는 것은 문제가 되며, 이 문제를 [[Man-in-the Middle]] (중간자 공격) 이라하며, 이 중간자 공격을 통하여 비밀키가 노출되어 위험할 수 있다. [[디피-헬만]] 알고리즘의 방법은 링크를 통해 알아볼 수 있다. |
− | |||
− | + | == 문제점 == | |
앞서 말했던 것 처럼, 디피-헬만 키 교환의 문제점은 중간자 공격 즉 [[Man-in-the Middle]] 이 가장 큰 문제점인데, 이것은 통신을 하는 대상과 비밀 정보를 공유할 수 있지만 상대방에 대한 인증은 전혀 보장이 되지 않는다. 예를 들어 A와 B가 비밀 키를 공유 할 때 중간에 C라는 공격자가 A에게는 B인척 B에게는 A인척 하여 접근을 하게 되면 A는 C를 보고 B라 생각하고, B는 C를 보고 A라 생각을 하게 되어 C가 A와 B의 대칭 키를 가질 수 있게 되는 것이다. | 앞서 말했던 것 처럼, 디피-헬만 키 교환의 문제점은 중간자 공격 즉 [[Man-in-the Middle]] 이 가장 큰 문제점인데, 이것은 통신을 하는 대상과 비밀 정보를 공유할 수 있지만 상대방에 대한 인증은 전혀 보장이 되지 않는다. 예를 들어 A와 B가 비밀 키를 공유 할 때 중간에 C라는 공격자가 A에게는 B인척 B에게는 A인척 하여 접근을 하게 되면 A는 C를 보고 B라 생각하고, B는 C를 보고 A라 생각을 하게 되어 C가 A와 B의 대칭 키를 가질 수 있게 되는 것이다. | ||
− | + | == 해결책 == | |
위와 같은 문제점을 해결하기 위해선 여러가지 방법이 있는데 그 방법은 다음과 같다. | 위와 같은 문제점을 해결하기 위해선 여러가지 방법이 있는데 그 방법은 다음과 같다. | ||
− | ''' OpenSSL 버전을 업데이트 ''' | + | |
+ | ''' 1. [[OpenSSL]] 버전을 업데이트 ''' | ||
OpenSSL 1.0.2 : 패치된 버전 1.0.2b 이상 | OpenSSL 1.0.2 : 패치된 버전 1.0.2b 이상 | ||
OpenSSL 1.0.1 : 패치된 버전 1.0.1n 이상 | OpenSSL 1.0.1 : 패치된 버전 1.0.1n 이상 | ||
− | ''' OpenSSL 1.0.1과 1.0.2대의 버전별 해결책 ''' | + | |
− | * 1.0.1과 1.0.2 : DH 파라미터가 768 비트보다 짧다면 | + | ''' OpenSSL 1.0.1과 1.0.2대의 버전별 해결책 ''' |
− | * | + | * 1.0.1과 1.0.2 : DH 파라미터가 768 비트보다 짧다면 [[handshake]]를 거부하도록 [[TLS 클라이언트]]에 대한 보호 기능을 추가 |
+ | * 1.0.2b 이상, 1.0.1n 이상 : 위 제한을 1024 비트까지 증가 | ||
+ | * 1.0.1m 이상, 1.0.2a 이상 : EXPORT cipher suite (수출등급 암호) 를 기본적으로 무능하게 만듬 | ||
+ | |||
+ | ''' 2. Diifie-Hellman 수출용 Cipher Suite 를 사용하지 않는다 ''' | ||
+ | |||
+ | ''' 3. ECDHE (Elliptic-Curve Hellman) 을 사용한다. ''' | ||
+ | * 타원 곡선형 디피-헬만 [[(ECDH)]] 키 교환 방식은 실현 가능하다고 알려진 모든 암호 해독학적 공격을 우회할 수 있다. 이러한 이유로 현대의 웹 브라우저들은 기존의 디피-헬만 방식보다 [[ECDHE]]방식을 선호 | ||
+ | |||
+ | ''' 4. Diffie-Hellman의 키 값을 2048bit 이상으로 생성, 적용 한다 ''' | ||
+ | |||
+ | == 참고 자료 == | ||
+ | * 〈[https://rsec.kr/?p=242 디피 헬만 키 (Diffie-Hellman Key) 를 2048 bit로 바꿔야 하는 이유]〉, 《개인블로그》, 2017-07-10 |
2019년 7월 4일 (목) 16:28 판
디피-헬만 키 교환 (Diffie-Hellman Key Exchange) 는 암호 키를 교환하는 방법으로, 디피-헬만 키 교환은 RSA와 마찬가지로 두 사람이 암호화 되지 않은 통신망을 통해 공통적인 비밀 키를 공유할 수 있도록 하는 것이다. 하지만 이 비밀키가 암호화 되어 통신망에서 지나가는 것은 문제가 되며, 이 문제를 Man-in-the Middle (중간자 공격) 이라하며, 이 중간자 공격을 통하여 비밀키가 노출되어 위험할 수 있다. 디피-헬만 알고리즘의 방법은 링크를 통해 알아볼 수 있다.
문제점
앞서 말했던 것 처럼, 디피-헬만 키 교환의 문제점은 중간자 공격 즉 Man-in-the Middle 이 가장 큰 문제점인데, 이것은 통신을 하는 대상과 비밀 정보를 공유할 수 있지만 상대방에 대한 인증은 전혀 보장이 되지 않는다. 예를 들어 A와 B가 비밀 키를 공유 할 때 중간에 C라는 공격자가 A에게는 B인척 B에게는 A인척 하여 접근을 하게 되면 A는 C를 보고 B라 생각하고, B는 C를 보고 A라 생각을 하게 되어 C가 A와 B의 대칭 키를 가질 수 있게 되는 것이다.
해결책
위와 같은 문제점을 해결하기 위해선 여러가지 방법이 있는데 그 방법은 다음과 같다.
1. OpenSSL 버전을 업데이트
OpenSSL 1.0.2 : 패치된 버전 1.0.2b 이상 OpenSSL 1.0.1 : 패치된 버전 1.0.1n 이상
OpenSSL 1.0.1과 1.0.2대의 버전별 해결책
- 1.0.1과 1.0.2 : DH 파라미터가 768 비트보다 짧다면 handshake를 거부하도록 TLS 클라이언트에 대한 보호 기능을 추가
- 1.0.2b 이상, 1.0.1n 이상 : 위 제한을 1024 비트까지 증가
- 1.0.1m 이상, 1.0.2a 이상 : EXPORT cipher suite (수출등급 암호) 를 기본적으로 무능하게 만듬
2. Diifie-Hellman 수출용 Cipher Suite 를 사용하지 않는다
3. ECDHE (Elliptic-Curve Hellman) 을 사용한다.
- 타원 곡선형 디피-헬만 (ECDH) 키 교환 방식은 실현 가능하다고 알려진 모든 암호 해독학적 공격을 우회할 수 있다. 이러한 이유로 현대의 웹 브라우저들은 기존의 디피-헬만 방식보다 ECDHE방식을 선호
4. Diffie-Hellman의 키 값을 2048bit 이상으로 생성, 적용 한다
참고 자료
- 〈디피 헬만 키 (Diffie-Hellman Key) 를 2048 bit로 바꿔야 하는 이유〉, 《개인블로그》, 2017-07-10