순방향 비밀 유지

Forward secrecy

FFS(Forward Secretary)는 암호학에서 완전한 순방향 비밀(PFS)이라고도 하며, 세션 키 교환에 사용된 장기적인 비밀이 손상되더라도 세션 키가 손상되지 않도록 보장하는 특정 키 합의 프로토콜의 기능입니다.HTTPS의 경우 장기적인 비밀은 일반적으로 서버의 개인 키입니다.순방향 기밀성은 향후 발생할 키나 비밀번호의 손상으로부터 과거 세션을 보호합니다.사용자가 시작하는 모든 세션에 대해 고유한 세션 키를 생성함으로써 단일 세션 키의 손상은 해당 특정 키에 의해 보호되는 특정 세션에서 교환되는 것 이외의 데이터에 영향을 미치지 않습니다.이 자체로는 순방향 기밀성만으로는 충분하지 않으므로 장기적인 비밀 침해가 과거 세션 키의 보안에 영향을 미치지 않아야 합니다.

순방향 비밀은 Heartbled 보안 버그와 같이 OpenSSL을 포함한 일반 전송 계층 보안 프로토콜을 사용하는 네트워크의 전송 계층에서 데이터를 보호합니다.순방향 비밀을 사용하는 경우, 상대가 앞으로 MITM(man-in-the-middle) 공격을 통해 적극적으로 개입하더라도 장기 비밀 키 또는 암호가 손상될 경우 과거에 기록된 암호화된 통신 및 세션을 검색하고 복호화할 수 없습니다.

순방향 비밀의 가치는 과거의 의사소통을 보호한다는 것입니다.이로 인해 공격자가 키를 손상할 동기가 줄어듭니다.예를 들어 공격자가 장기 키를 학습했지만 손상이 감지되어 장기 키가 취소되고 업데이트되는 경우 순방향 보안 시스템에서 유출되는 정보는 상대적으로 적습니다.

순방향 비밀의 가치는 상대의 가정된 능력에 따라 달라집니다.상대가 장치에서 비밀 키를 얻을 수 있다고 가정(읽기 액세스)하지만 장치에서 세션 키가 생성되는 방식을 수정할 수 없거나 탐지된 경우(완전한 손상)에는 값이 있습니다.어떤 경우에는 장치에서 장기 키를 읽을 수 있는 상대가 백도어 듀얼 타원 곡선 결정론적 랜덤 비트 생성기처럼 세션 키 생성기의 기능을 수정할 수도 있습니다.만약 적수가 난수 생성기를 예측 가능하게 만들 수 있다면, 과거의 트래픽은 보호되지만 미래의 모든 트래픽은 손상됩니다.

순방향 비밀의 가치는 공격자가 키만 훔치고 서버가 사용하는 난수 생성기는 수정하지 않음으로써 공격할 것이라는 가정에 의해 제한될 뿐만 아니라, 상대가 수동적으로 통신 링크의 트래픽을 수집할 뿐이고 맨인트를 사용하여 능동적이지 않을 것이라는 가정에 의해 제한됩니다.중간 공격순방향 비밀은 일반적으로 덧없음 디피를 사용합니다.과거 트래픽 읽기를 방지하기 위한 헬맨 키 교환.덧없는 디피-헬만 키 교환은 정적 서명 키를 사용하여 서버에 의해 서명되는 경우가 많습니다.상대가 이 정적(장기) 서명 키를 탈취(또는 법원 명령을 통해 입수)할 수 있는 경우, 상대는 서버를 클라이언트로, 클라이언트를 서버로 가장하여 전형적인 중간자 [1]공격을 구현할 수 있습니다.

역사

"완벽한 순방향 비밀"이라는 용어는 1990년 C[2]. G. 귄터에 의해 만들어졌고, 1992년 휘트필드 디피, 폴 반 오어쇼트, 마이클 제임스[3] 위너에 의해 더 논의되어 스테이션 대 스테이션 [4]프로토콜의 속성을 설명하는 데 사용되었습니다.

또한 순방향 비밀은 암호 인증 키 합의 프로토콜의 유사한 속성을 설명하는 데 사용되었으며, 여기서 장기 비밀은 (공유) [5]암호입니다.

2000년에 IEEE는 다양한 표준 키 협정 [6]체계의 관련 1자 및 2자 순방향 비밀 보호 속성을 설정하는 IEEE 1363을 처음으로 비준했습니다.

정의.

암호화 시스템은 세션 시작의 키 합의 단계에서 발생하는 데이터 교환에 대한 일반 텍스트(암호화되지 않은) 검사에서 세션의 나머지를 암호화하는 데 사용된 키가 나타나지 않으면 순방향 비밀화 속성을 가집니다.

예

다음은 순방향 비밀을 사용하는 간단한 인스턴트 메시징 프로토콜의 가상적인 예입니다.

  1. Alice와 Bob은 각각 한 쌍의 장기적이고 비대칭적인 공개 키와 개인 키를 생성한 다음 직접 또는 이미 인증된 채널을 통해 공개 키 지문을 확인합니다.검증은 공개키의 주장된 소유자가 실제 소유자라는 확신을 가지고 확립합니다.
  2. 앨리스와 밥은 디피와 같은 키 교환 알고리즘을 사용합니다.헬맨, 임시 세션 키에 대해 안전하게 동의합니다.이 과정에서 1단계의 키를 서로 인증하는 데만 사용합니다.
  3. Alice는 Bob에게 메시지를 보내고, 2단계에서 협상된 세션 키를 사용하여 대칭 암호로 암호화합니다.
  4. Bob은 2단계에서 협상된 키를 사용하여 Alice의 메시지를 해독합니다.
  5. 이 프로세스는 2단계부터 전송된 새 메시지마다 반복되며, 앨리스와 밥의 역할을 보내는 사람/받는 사람으로 바꿉니다.1단계는 반복되지 않습니다.

순방향 비밀(각 메시지에 대한 새로운 세션 키를 생성하여 달성)은 2단계 반복에서 생성된 키 중 하나가 손상된 경우 과거 통신을 해독할 수 없도록 보장합니다. 이러한 키는 단일 메시지를 암호화하는 데만 사용되기 때문입니다.순방향 비밀은 또한 1단계의 장기 개인 키가 손상된 경우 과거 통신의 암호를 해독할 수 없도록 보장합니다.하지만 이런 일이 발생하면 앞으로 앨리스나 밥으로 가장하는 것이 가능할 것이며, 향후 모든 메시지를 손상시킬 수도 있습니다.

공격

전방 비밀은 장기 비밀키의 손상이 과거 대화의 기밀에 영향을 미치지 않도록 설계되었습니다.그러나 암호 분석은 키 없이 암호화된 메시지를 해독하는 방법을 찾는 것으로 구성되며, 순방향 암호는 암호 [7]자체가 아닌 키만 보호하기 때문에 순방향 암호는 사용되는 기본 암호의 성공적인 암호 분석을 방어할 수 없습니다.환자 공격자는 공개 키 암호를 사용하여 기밀성이 보호되는 대화를 캡처하고 기본 암호가 깨질 때까지 기다릴 수 있습니다(예: 이산 로그 문제를 빠르게 계산할 수 있는 대형 양자 컴퓨터가 생성될 수 있음).이를 통해 순방향 기밀을 사용하는 시스템에서도 오래된 평문을 복구할 수 있습니다.

대화형이 아닌 순방향 보안 키 교환 프로토콜은 대화형 프로토콜과 관련이 없는 추가적인 위협에 직면합니다.메시지 억제 공격에서는 네트워크를 제어하는 공격자가 메시지를 저장하는 동시에 메시지가 의도된 수신자에게 도달하지 못하게 할 수 있습니다. 메시지가 수신되지 않으므로 해당 개인 키가 파괴되거나 구멍이 나지 않을 수 있으므로 개인 키의 손상으로 인해 암호 해독이 성공할 수 있습니다.사전에 일정에 따라 개인 키를 폐기하면 이러한 공격이 완화되지만 제거되지는 않습니다.악의적인 키 소진 공격에서 공격자는 수신자에게 많은 메시지를 보내고 개인 키 자료를 소진하여 프로토콜이 폐쇄 실패(및 서비스 거부 공격 활성화) 또는 개방 실패(그리고 어느 정도의 순방향 비밀 유지)[8] 중 하나를 선택하도록 합니다.

비대화형 순방향 기밀성

대부분의 키 교환 프로토콜은 대화형이므로 당사자 간에 양방향 통신이 필요합니다.송신자가 먼저 수신자로부터 아무런 응답을 받을 필요 없이 데이터를 전송할 수 있도록 허용하는 프로토콜은 비대화형, 비동기형, 또는 제로 라운드 트립(0-RTT)[9][10]이라고 할 수 있습니다.

상호작용성은 일부 애플리케이션에 부담이 됩니다. 예를 들어, 보안 메시징 시스템에서는 송신자와 수신자가 동시에 온라인 상태가 될 것을 요구하는 것보다 저장 및 전달(store-forward) 구현이 바람직할 수 있습니다. 양방향성 요구사항을 완화하는 것은 엄격한 요구사항이 아닌 경우에도 성능을 향상시킬 수 있습니다.예를 들어, 연결 설정 또는 재개 시.이러한 사용 사례는 비 상호작용적 키 교환에 대한 관심을 자극했으며, 순방향 보안이 키 교환 프로토콜에서 바람직한 속성이므로 비 상호작용적 순방향 비밀 [11][12]유지에 대한 관심을 높였습니다.이 조합은 적어도 [13]1996년부터 바람직한 것으로 확인되었습니다.그러나 순방향 비밀성과 비상호작용성을 결합하는 [14]것은 어려운 것으로 입증되었습니다. 재생 공격에 대한 보호 기능을 갖춘 순방향 비밀성은 비상호작용적으로 불가능하다고 의심되어 왔지만, 세 가지 목적 [10]데이터를 모두 달성하는 것이 가능한 것으로 나타났습니다.

전반적으로, 비 상호작용적 포워드 기밀성에 대한 두 가지 접근법, 즉 사전 계산된 키와 펑처블 [12]암호화가 탐구되었습니다.

사전 계산된 키를 사용하면 많은 키 쌍이 생성되고 공용 키가 공유되며, 해당 공용 키를 사용하여 메시지가 수신된 후 개인 키가 삭제됩니다.이 접근 방식은 신호 [15]프로토콜의 일부로 배포되었습니다.

펑처블 암호화에서 수신자는 메시지를 수신한 후 새 개인 키는 메시지를 읽을 수 없지만 공개 키는 변경되지 않는 방식으로 개인 키를 수정합니다.Ross J. Anderson은 1997년에 [16]순방향 보안 키 교환을 위한 천공 가능한 암호화 체계를 비공식적으로 설명했고, Green & Miers(2015)는 Canetti, Halevi & Katz(2003)의 관련 체계를 기반으로 하여 그러한 [17]체계를 공식적으로 설명했습니다.이전 기간에 보낸 메시지를 나중 [14]기간의 개인 키로 읽을 수 없도록 일정에 따라 개인 키를 수정합니다.Gunther et al. (2017)은 계층적 정체성 기반 암호화와 속성 기반 암호화를 사용하는 반면, Green & Miers (2015)는 계층적 정체성 기반 [18]체계를 기반으로 할 수 있는 다른 구성을 사용하고 있습니다.Dallmeier et al. (2020)은 실험적으로 천공 가능한 암호화로 구현된 0-RTT 순방향 보안 및 재생 저항 키 교환을 사용하도록 QUIC를 수정하면 리소스 사용량이 크게 증가하지만 실제 사용이 [19]불가능하지는 않다는 것을 발견했습니다.

취약한 완벽한 전방 비밀 유지

약한 완벽한 순방향 비밀성(Wpfs)은 에이전트의 장기 키가 손상되었을 때 이전에 설정된 세션 키의 비밀성이 보장되지만, 상대가 적극적으로 개입하지 않은 세션에 대해서만 보장되는 약한 속성입니다.이 새로운 개념, 그리고 이것과 전방 비밀의 구별은 2005년 [20][21]휴고 크라크칙에 의해 도입되었습니다.이 약한 정의는 암묵적으로 완전한(완벽한) 전방 비밀이 상대방이 적극적으로 간섭하거나 중간에서 사람처럼 행동하려고 시도하는 세션에서도 이전에 설정된 세션 키의 비밀을 유지하도록 요구합니다.

프로토콜

순방향 비밀성은 SSH와 같은 몇 가지 주요 프로토콜 구현에 존재하며 IPsec(RFC 2412)의 옵션 기능으로 존재합니다.많은 인스턴트 메시징 클라이언트를 위한 암호화 프로토콜 및 라이브러리인 오프 더 레코드 메시징과 이러한 클라이언트에서 다중 사용자 기능과 같은 추가 기능을 제공하는 OMEMO는 모두 순방향 암호화뿐만 아니라 거부 가능한 암호화를 제공합니다.

TLS(Transport Layer Security)에서 Diffie를 기반으로 한 암호 제품군 -헬만 키 교환(DHE-RSA, DHE-DSA)과 타원 곡선 Diffie-헬만 키 교환(ECDHE-RSA, ECDHE-ECDSA)이 가능합니다.이론적으로, TLS는 SSLv3 이후 적절한 암호를 선택할 수 있었지만, 일상적으로 많은 구현이 순방향 암호화를 제공하는 것을 거부하거나 매우 낮은 암호화 [22]등급만을 제공했습니다.이것은 더 이상 TLS 1.3의 경우에는 해당되지 않습니다. TLS 1.3의 경우에는 더 이상 사용하지 않는 Diffie를 남김으로써 순방향 비밀을 보장합니다.헬만(무한장 및 [23]타원 곡선 변형)이 유일하게 남아있는 키 교환 메커니즘입니다.

OpenSSL은 타원 곡선 Diffie를 사용하여 전방 비밀 유지를 지원합니다.버전 1.0 [24]이후의 헬맨, 초기 [25]핸드셰이크에 대한 계산 오버헤드가 약 15%입니다.

신호 프로토콜은 이중 래칫 알고리즘을 사용하여 순방향 비밀을 [26]제공합니다.

한편, 현재 사용되고 있는 일반적인 프로토콜 중 WPA는 순방향 비밀 보호를 지원하지 않습니다.

사용하다

순방향 기밀성은 몇몇 대형 인터넷 정보 제공자들에게 중요한 보안 기능으로 여겨집니다.2011년 말부터 구글은 기본적으로 Gmail 서비스, 구글 문서 서비스, 암호화된 검색 [24]서비스의 사용자에게 TLS를 제공했습니다.트위터는 2013년 11월부터 [27]TLS로 순방향 기밀을 사용자에게 제공했습니다.Wikimedia Foundation이 주최하는 Wiki는 2014년 7월부터[28] 모두 순방향 비밀을 사용자에게 제공하고 있으며, 2018년 8월부터 순방향 비밀을 사용하도록 요구하고 있습니다.

Facebook은 이메일 암호화에 대한 조사의 일환으로 2014년 5월 현재 STARTTLS를 지원하는 호스트의 74%가 순방향 [29]기밀성도 제공한다고 보고했습니다.2018년 8월에 발표된 TLS 1.3은 순방향 비밀 없이 암호에 대한 지원을 중단했습니다.2019년 2월 현재 조사 대상 웹 서버의 96.6%가 어떤 형태로든 순방향 비밀을 지지하고 있으며 52.1%는 대부분의 [30]브라우저에서 순방향 비밀을 사용할 것입니다.

WWDC 2016에서 애플은 모든 iOS 앱이 HTTPS 전송을 강제하는 기능인 ATS(App Transport Security)를 사용해야 한다고 발표했습니다.특히 ATS는 순방향 [31]비밀성을 제공하는 암호화 암호를 사용해야 합니다.ATS는 2017년 1월 [32]1일부터 앱에 의무화되었습니다.

Signal messaging application은 프로토콜에 순방향 비밀을 사용하며, 특히 PGP를 [33]기반으로 하는 메시징 프로토콜과 구별됩니다.

참고 항목

참고문헌

  1. ^ "tls - Does Perfect Forward Secrecy (PFS) make Man-in-the-Middle (MitM) attacks more difficult?". Information Security Stack Exchange. Retrieved 2020-10-11.
  2. ^ Günther, C. G. (1990). An identity-based key-exchange protocol. Advances in Cryptology EUROCRYPT '89 (LNCS 434). pp. 29–37.
  3. ^ Menzies, Alfred; van Oorscot, Paul C; Vanstone, SCOTT (1997). Handbook of Applied Cryptography. CRC Pres. ISBN 978-0-8493-8523-0.
  4. ^ Diffie, Whitfield; van Oorschot, Paul C.; Wiener, Michael J. (June 1992). "Authentication and Authenticated Key Exchanges" (PDF). Designs, Codes and Cryptography. 2 (2): 107–125. CiteSeerX 10.1.1.59.6682. doi:10.1007/BF00124891. S2CID 7356608. Retrieved 2013-09-07.
  5. ^ Jablon, David P. (October 1996). "Strong Password-Only Authenticated Key Exchange". ACM Computer Communication Review. 26 (5): 5–26. CiteSeerX 10.1.1.81.2594. doi:10.1145/242896.242897. S2CID 2870433.
  6. ^ "IEEE 1363-2000 - IEEE Standard Specifications for Public-Key Cryptography". standards.ieee.org. Retrieved 2018-06-14.
  7. ^ Nilsson, Dennis K.; Roosta, Tanya; Lindqvist, Ulf; Valdes, Alfonso (2008-03-31). "Key management and secure software updates in wireless process control environments". Proceedings of the first ACM conference on Wireless network security. WiSec '08. Alexandria, VA, USA: Association for Computing Machinery. pp. 100–108. doi:10.1145/1352533.1352550. ISBN 978-1-59593-814-5. S2CID 15382932.
  8. ^ 보이드 & 겔러트 2020, 페이지 645.
  9. ^ Boyd & Gellert 2020, 페이지 639-640.
  10. ^ a b Gunther et al. 2017, p. 1.
  11. ^ 보이드 & 겔러트 2020, 페이지 640.
  12. ^ a b 보이드 & 겔러트 2020, 페이지 643.
  13. ^ 지난 1996년.
  14. ^ a b 그린 & 마이어스 2015, 페이지 1.
  15. ^ Boyd & Gellert 2020, 페이지 644-645
  16. ^ 앤더슨 2002.
  17. ^ Boyd & Gellert 2020, 페이지 643-644.
  18. ^ Gunther et al. 2017, p. 5.
  19. ^ Dallmeier et al. 2020, p. 18-19.
  20. ^ Krawczyk, Hugo (2005). HMQV: A High-Performance Secure Diffie-Hellman Protocol. Advances in Cryptology – CRYPTO 2005. Lecture Notes in Computer Science. Vol. 3621. pp. 546–566. doi:10.1007/11535218_33. ISBN 978-3-540-28114-6.
  21. ^ Cremers, Cas; Feltz, Michèle (2015). "Beyond eCK: perfect forward secrecy under actor compromise and ephemeral-key reveal" (PDF). Designs, Codes and Cryptography. 74 (1): 183–218. CiteSeerX 10.1.1.692.1406. doi:10.1007/s10623-013-9852-1. hdl:20.500.11850/73097. S2CID 53306672. Retrieved 8 December 2015.
  22. ^ 2007년 10월 TLS 메일링 리스트 논의
  23. ^ "A Detailed Look at RFC 8446 (a.k.a. TLS 1.3)". The Cloudflare Blog. 2018-08-10. Retrieved 2019-02-26.
  24. ^ a b "Protecting data for the long term with forward secrecy". Retrieved 2012-11-05.
  25. ^ Vincent Bernat (28 November 2011). "SSL/TLS & Perfect Forward Secrecy". Retrieved 2012-11-05.
  26. ^ Unger, Nik; Dechand, Sergej; Bonneau, Joseph; Fahl, Sascha; Perl, Henning; Goldberg, Ian; Smith, Matthew (17–21 May 2015). "SoK: Secure Messaging". 2015 IEEE Symposium on Security and Privacy (PDF). San Jose, CA: Institute of Electrical and Electronics Engineers. p. 241. doi:10.1109/SP.2015.22. ISBN 978-1-4673-6949-7. S2CID 2471650. Retrieved 4 December 2015.
  27. ^ Hoffman-Andrews, Jacob. "Forward Secrecy at Twitter". Twitter. Retrieved 25 November 2013.
  28. ^ "Tech/News/2014/27 - Meta". Wikimedia Foundation. 2014-06-30. Retrieved 30 June 2014.
  29. ^ "The Current State of SMTP STARTTLS Deployment". Facebook. Retrieved 7 June 2014.
  30. ^ Qualys SSL Labs. "SSL Pulse". Archived from the original (3 February 2019) on 15 February 2019. Retrieved 25 February 2019.
  31. ^ "iOS 9.0".
  32. ^ "App Transport Security REQUIRED January 2017 Apple Developer Forums". forums.developer.apple.com. Retrieved 2016-10-20.
  33. ^ Evans, Jon (22 January 2017). "WhatsApp, Signal, and dangerously ignorant journalism". TechCrunch. Retrieved 18 April 2018.

서지학

외부 링크