전방향 보안

[300px|섬네일|오른쪽|[키 유도 함수 (KDF)는 전방향 보안을 달성하는 데 도움이 될 수 있다. KDF는 현재 키에서 새 키를 생성하는 단방향 함수이다. 키가 유출되더라도 이전 키를 알아낼 수는 없다.]]

암호학에서 **전방향 보안**(forward secrecy, **FS**), **전방향 안정성**, **완전 전방향 보안**(perfect forward secrecy, **PFS**)은 세션 키 교환에 사용되는 장기 비밀 키가 손상되더라도 세션 키가 손상되지 않도록 보장하여 피해를 제한하는 특정 키 교환 프로토콜의 기능이다. TLS의 경우, 장기 비밀 키는 일반적으로 서버의 개인 키이다. 전방향 보안은 키나 비밀번호가 미래에 손상되더라도 과거 세션을 보호한다. 사용자가 시작하는 모든 세션에 대해 고유한 세션 키를 생성함으로써, 단일 세션 키가 손상되더라도 해당 키로 보호되는 특정 세션에서 교환된 데이터 외에는 어떤 데이터에도 영향을 미치지 않는다. 이는 그 자체로 전방향 보안에 충분하지 않으며, 전방향 보안은 추가적으로 장기 비밀 키 손상이 과거 세션 키의 보안에 영향을 미치지 않아야 한다.

전방향 보안은 하트블리드 보안 버그와 같이 장기 비밀 키가 손상될 경우, OpenSSL을 포함한 일반적인 전송 계층 보안 프로토콜을 사용하는 네트워크의 전송 계층에서 데이터를 보호한다. 전방향 보안이 사용되면, 암호화된 통신 및 과거에 기록된 세션은 장기 비밀 키나 비밀번호가 미래에 손상되더라도 검색하거나 해독할 수 없다. 이는 공격자가 중간자 (MITM) 공격을 통해 적극적으로 개입했더라도 마찬가지이다.

전방향 보안의 가치는 과거 통신을 보호한다는 점에 있다. 이는 공격자가 키를 침해하려는 동기를 줄인다. 예를 들어, 공격자가 장기 키를 알게 되었지만, 침해 사실이 감지되어 장기 키가 폐기 및 업데이트될 경우, 전방향 보안 시스템에서는 비교적 적은 정보만 유출된다.

전방향 보안의 가치는 공격자의 가정된 능력에 따라 달라진다. 공격자가 장치에서 비밀 키를 얻을 수 있지만(읽기 접근 권한), 세션 키가 장치에서 생성되는 방식을 수정할 수 없거나(완전 침해) 침해가 감지되는 경우에 전방향 보안은 가치가 있다. 어떤 경우에는 장치에서 장기 키를 읽을 수 있는 공격자가 백도어 Dual Elliptic Curve Deterministic Random Bit Generator와 같이 세션 키 생성기의 기능을 수정할 수도 있다. 공격자가 난수 생성기를 예측 가능하게 만들 수 있다면, 과거 트래픽은 보호되지만 미래의 모든 트래픽은 손상될 것이다.

전방향 보안의 가치는 공격자가 서버에서 키를 훔치기만 하고 서버에서 사용되는 난수 생성기를 수정하지 않을 것이라는 가정에 의해서만 제한되는 것이 아니라, 통신 링크에서 수동적으로 트래픽을 수집할 뿐 중간자 공격을 사용하지 않을 것이라는 가정에 의해서도 제한된다. 전방향 보안은 일반적으로 과거 트래픽을 읽는 것을 방지하기 위해 임시 디피-헬먼 키 교환을 사용한다. 임시 디피-헬먼 키 교환은 종종 정적 서명 키를 사용하여 서버에 의해 서명된다. 공격자가 이 정적 (장기) 서명 키를 훔치거나 (또는 법원 명령을 통해 얻을 수 있다면), 공격자는 클라이언트에게 서버로, 서버에게 클라이언트로 가장하여 고전적인 중간자 공격을 구현할 수 있다.

## 역사
"완전 전방향 보안"이라는 용어는 1990년 C. G. 귄터(C. G. Günther)에 의해 만들어졌으며 1992년 휫필드 디피, 폴 반 오르숏(Paul van Oorschot), 마이클 제임스 위너(Michael James Wiener)에 의해 추가로 논의되었다. 여기서 이 용어는 Station-to-Station 프로토콜의 속성을 설명하는 데 사용되었다.

전방향 보안은 장기 비밀이 (공유) 비밀번호인 비밀번호 인증 키 합의 프로토콜의 유사한 속성을 설명하는 데에도 사용되었다.

2000년 IEEE는 다양한 표준 키 합의 방식의 관련 일대일 및 양대 전방향 보안 속성을 설정하는 IEEE 1363을 처음 비준했다.

## 정의
암호화 시스템은 세션 시작의 키 합의 단계에서 발생하는 데이터 교환에 대한 평문(암호 해독된) 검사가 나머지 세션 암호화에 사용된 키를 드러내지 않는 경우 전방향 보안 속성을 가진다.

## 예시

다음은 전방향 보안을 사용하는 간단한 인스턴트 메시징 프로토콜의 가상 예시이다.

# 앨리스와 밥은 각각 장기 비대칭 공개 키와 개인 키 쌍을 생성한 다음, 직접 또는 이미 인증된 채널을 통해 공개 키 지문을 확인한다. 이 확인은 공개 키의 주장된 소유자가 실제 소유자임을 확신하게 한다.
# 앨리스와 밥은 디피-헬먼 키 교환과 같은 키 교환 알고리즘을 사용하여 임시 세션 키에 안전하게 합의한다. 이 과정에서 1단계의 키는 서로를 인증하는 데만 사용된다.
# 앨리스는 2단계에서 협상된 세션 키를 사용하여 대칭 암호로 메시지를 암호화하여 밥에게 보낸다.
# 밥은 2단계에서 협상된 키를 사용하여 앨리스의 메시지를 해독한다.
# 새 메시지를 보낼 때마다 2단계부터 이 과정이 반복된다 (적절하게 앨리스와 밥의 송신자/수신자 역할이 바뀐다). 1단계는 다시 반복되지 않는다.
전방향 보안(각 메시지에 대해 새 세션 키를 생성함으로써 달성됨)은 2단계 반복에서 생성된 키 중 하나가 손상되더라도 이전 통신을 해독할 수 없도록 보장한다. 왜냐하면 그러한 키는 단일 메시지를 암호화하는 데만 사용되기 때문이다. 전방향 보안은 1단계의 장기 개인 키가 손상되더라도 이전 통신을 해독할 수 없도록 보장한다. 그러나 이러한 일이 발생하면 앨리스나 밥으로 가장하는 것이 가능해져서 모든 미래 메시지가 손상될 수 있다.

## 공격
전방향 보안은 장기 비밀 키 손상이 과거 대화의 기밀성에 영향을 미치는 것을 방지하기 위해 설계되었다. 그러나 전방향 보안은 사용되는 기본 암호의 성공적인 암호 해독으로부터 방어할 수 없다. 왜냐하면 암호 해독은 키 없이 암호화된 메시지를 해독하는 방법을 찾는 것으로 구성되며, 전방향 보안은 암호 자체가 아닌 키만 보호하기 때문이다. 인내심 있는 공격자는 공개 키 암호 방식을 사용하여 기밀성이 보호되는 대화를 캡처하고, 기본 암호가 깨질 때까지 기다릴 수 있다 (예: 큰 양자 컴퓨터가 생성되어 이산 로그 문제를 빠르게 계산할 수 있게 될 때까지). 이를 지금 수집하고 나중에 해독 공격이라고도 한다. 이 경우 전방향 보안을 사용하는 시스템에서도 오래된 평문을 복구할 수 있다.

비대화형 전방향 보안 키 교환 프로토콜은 대화형 프로토콜과는 관련 없는 추가적인 위협에 직면한다. 메시지 억제 공격에서, 네트워크를 제어하는 공격자는 메시지가 의도한 수신자에게 도달하는 것을 방지하면서 메시지를 스스로 저장할 수 있다. 메시지가 수신되지 않으면 해당 개인 키가 파괴되거나 천공되지 않을 수 있으므로, 개인 키의 침해는 성공적인 해독으로 이어질 수 있다. 정기적으로 개인 키를 선제적으로 폐기하는 것은 이 공격을 완화하지만 제거하지는 못한다. 악의적인 키 고갈 공격에서, 공격자는 수신자에게 많은 메시지를 보내 개인 키 자료를 고갈시켜 프로토콜이 폐쇄적으로 실패하거나(그리고 서비스 거부 공격을 가능하게 하거나) 개방적으로 실패하도록(그리고 어느 정도의 전방향 보안을 포기하도록) 강요한다.

## 비대화형 전방향 보안
대부분의 키 교환 프로토콜은 상호작용적이며, 당사자 간의 양방향 통신을 필요로 한다. 발신자가 수신자로부터 어떤 응답도 먼저 받을 필요 없이 데이터를 전송할 수 있도록 허용하는 프로토콜은 비대화형, 비동기식, 또는 제로 왕복 (0-RTT)이라고 불릴 수 있다.

상호작용성은 일부 애플리케이션에 부담이 된다. 예를 들어, 보안 메시징 시스템에서는 발신자와 수신자가 동시에 온라인 상태일 필요 없이 저장-전달 구현을 갖는 것이 바람직할 수 있다. 양방향성 요구 사항을 완화하면 엄격한 요구 사항이 아닌 경우에도 성능을 향상시킬 수 있다. 예를 들어 연결 설정 또는 재개 시에 그렇다. 이러한 사용 사례는 비대화형 키 교환에 대한 관심을 자극했으며, 키 교환 프로토콜에서 전방향 보안이 바람직한 속성이므로 비대화형 전방향 보안에 대한 관심도 자극했다. 이러한 조합은 적어도 1996년부터 바람직하다고 여겨져 왔다. 그러나 전방향 보안과 비대화성을 결합하는 것은 어려운 것으로 판명되었다. 재전송 공격에 대한 보호를 갖춘 전방향 보안은 비대화적으로는 불가능할 것으로 의심되었지만, 세 가지 바람직한 속성을 모두 달성하는 것이 가능하다는 것이 입증되었다.

대체적으로, 비대화형 전방향 보안에는 사전 계산된 키와 천공 가능한 암호화라는 두 가지 접근 방식이 탐구되어 왔다.

사전 계산된 키를 사용하면 많은 키 쌍이 생성되고 공개 키가 공유되며, 해당 공개 키를 사용하여 메시지가 수신된 후 개인 키는 파괴된다. 이 접근 방식은 시그널 프로토콜의 일부로 배포되었다.

천공 가능한 암호화에서 수신자는 메시지를 받은 후 개인 키를 수정하여 새 개인 키가 메시지를 읽을 수 없지만 공개 키는 변경되지 않도록 한다. 로스 앤더슨은 1997년에 전방향 보안 키 교환을 위한 천공 가능한 암호화 스키마를 비공식적으로 설명했으며, 는 그러한 시스템을 공식적으로 설명했다. 이는 의 관련 스키마를 기반으로 하며, 이 스키마는 스케줄에 따라 개인 키를 수정하여 이전 기간에 보낸 메시지를 나중 기간의 개인 키로 읽을 수 없도록 한다. 는 계층적 ID 기반 암호화와 속성 기반 암호화를 사용하는 반면, 는 어떤 계층적 ID 기반 스키마에도 기반할 수 있는 다른 구성을 사용한다. 는 천공 가능한 암호화로 구현된 0-RTT 전방향 보안 및 재전송 방지 키 교환을 사용하도록 QUIC을 수정하는 것이 리소스 사용량을 크게 증가시켰지만, 실제 사용이 불가능할 정도는 아니라는 것을 실험적으로 발견했다.

## 약한 완전 전방향 보안
약한 완전 전방향 보안(Wpfs)은 에이전트의 장기 키가 손상될 때 이전에 설정된 세션 키의 비밀이 보장되지만, 적이 적극적으로 개입하지 않은 세션에만 해당되는 약한 속성이다. 이 새로운 개념과 전방향 보안과의 구별은 2005년 휴고 크라우치크(Hugo Krawczyk)에 의해 도입되었다.
이 약한 정의는 완전 (완벽한) 전방향 보안이 적이 적극적으로 개입했거나 중간자 역할을 시도한 세션에서도 이전에 설정된 세션 키의 비밀을 유지한다고 암시적으로 요구한다.

## 프로토콜
전방향 보안은 SSH와 같은 여러 프로토콜 구현과 IPsec의 선택적 기능(RFC 2412)에 존재한다. 많은 인스턴트 메시징 클라이언트를 위한 암호화 프로토콜 및 라이브러리인 오프 더 레코드 메시징(Off-the-Record Messaging)과 이러한 클라이언트에서 다중 사용자 기능과 같은 추가 기능을 제공하는 OMEMO는 모두 전방향 보안과 부인 방지 암호화를 제공한다.

TLS에서는 디피-헬먼 키 교환 (DHE-RSA, DHE-DSA) 및 타원 곡선 디피-헬먼 키 교환 (ECDHE-RSA, ECDHE-ECDSA)을 기반으로 하는 암호 스위트를 사용할 수 있다. 이론적으로 TLS는 SSLv3부터 전방향 보안을 사용할 수 있지만, 많은 구현이 전방향 보안을 제공하지 않거나 낮은 등급의 암호화로 제공했다. TLS 1.3은 키 교환을 위한 RSA 지원을 제거하고, 디피-헬먼(전방향 보안 포함)을 유일한 키 교환 알고리즘으로 남겨두었다.

OpenSSL은 버전 1.0부터 타원 곡선 디피-헬먼을 사용하여 전방향 보안을 지원하며, 초기 핸드셰이크에 약 15%의 계산 오버헤드가 발생한다.

시그널 프로토콜은 더블 래칫 알고리즘(Double Ratchet Algorithm)을 사용하여 전방향 보안을 제공한다.

반면, 현재 사용되는 인기 있는 프로토콜 중 WPA Personal은 WPA3 이전에 전방향 보안을 지원하지 않았다.

## 사용
2011년 말부터 구글은 Gmail 서비스, 구글 문서 서비스 및 암호화된 검색 서비스 사용자에게 기본적으로 TLS를 통한 전방향 보안을 제공했다. 2013년 11월부터 트위터는 사용자에게 TLS를 통한 전방향 보안을 제공했다. 위키미디어 재단이 호스팅하는 모든 위키는 2014년 7월부터 사용자에게 전방향 보안을 제공했으며, 2018년 8월부터 전방향 보안 사용을 의무화했다.

페이스북은 이메일 암호화 조사 결과의 일환으로 2014년 5월 현재 STARTTLS를 지원하는 호스트의 74%가 전방향 보안도 제공한다고 보고했다. 2018년 8월에 발행된 TLS 1.3은 전방향 보안이 없는 암호 지원을 중단했다. 2019년 2월 기준, 설문 조사된 웹 서버의 96.6%가 어떤 형태의 전방향 보안을 지원하며, 52.1%는 대부분의 브라우저에서 전방향 보안을 사용할 것이다.

WWDC 2016에서 애플은 모든 iOS 앱이 HTTPS 전송 사용을 강제하는 App Transport Security (ATS) 기능을 사용해야 한다고 발표했다. 특히 ATS는 전방향 보안을 제공하는 암호화 암호 사용을 요구한다. ATS는 2017년 1월 1일부터 앱에 의무화되었다.

시그널 메시징 애플리케이션은 프로토콜에 전방향 보안을 사용하며, 특히 PGP 기반 메시징 프로토콜과 차별화된다.

현대 브라우저에서 전방향 보안은 92.6%의 웹사이트에서 지원되며, 2024년 5월 현재 0.3%의 웹사이트는 전방향 보안을 전혀 지원하지 않는다.

## 같이 보기
* 전방향 익명성
* 디피-헬먼 키 교환
* 타원 곡선 디피-헬먼
* 지금 수집하고 나중에 해독

## 각주

## 참고 문헌
* 
* 
* 
* 
* 
* 
* 

## 외부 링크
*  IETF, H. Orman. The OAKLEY Key Determination Protocol
* 완전 전방향 보안은 NSA가 보안 웹 페이지를 보지 못하게 할 수 있지만, 아무도 사용하지 않는다 Computerworld 2013년 6월 21일
* SSL: 오늘 가로채기, 내일 해독 Netcraft 2013년 6월 25일
* 전방향 보안 배포 SSL Labs 2013년 6월 25일
* 웹 브라우저용 SSL Labs 테스트
* 웹 서버용 SSL Labs 테스트

분류:키 관리
분류:공개 키 암호
분류:전송 계층 보안