대개 암호화 알고리듬과 프로토콜은 시스템을 안전하게 하기 위해 특히 인터넷과 같은 신뢰되지 않은 네트워크를 통해 통신할 때 필요하다. 가능한 정보를 인증하고 정보를 비밀로 유지하기 위해 암호학적인 기법을 사용해라 (단순한 암호화가 또한 자동적으로 인증할 수 있다고 가정하지 마라). 일반적으로 애플리케이션을 안전하게 하기 위해 사용가능한 도구를 사용할 필요가 있다.
배경 정보와 코드에 대해서는 아마도 고전적인 텍스트 ``Applied Cryptography" [Schneier 1996] 를 봐야 한다. 뉴스그룹 ``sci.crypt" 에는 일련의 FAQ 이 있는데 http://www.landfiel d.com/faqs/cryptography-faq 을 포함한 많은 위치에서 이들을 찾을 수 있다. 리눅스에 특정적인 자원들은 http://marc.mutz.com/Encryption-HOWTO/에 있는 Linux Encryption HOWTO 를 포함한다. 프로토콜이 기본적인 알고리듬을 사용하는 방법에 관한 논의는 [Opplinger 1998] 에서 찾을 수 있다. 프로토콜에서 암호학을 적용하는 방법에 관한 유용한 논문 모음은 [Stallings 1996] 에서 찾을 수 있다. 다음은 단지 약간의 설명문으로 이 분야는 상당히 전문화되어 있으며 다른 곳에서 더욱 철저히 다뤄지고 있다.
암호화 프로토콜과 알고리듬을 올바르게 이해하기는 어렵다. 따라서 각자 스스로 이들을 만들지 마라. 대신 될 수 있는한 널리 사용되고 있고 깊히 분석되었으며 보안적이라고 받아들여진 프로토콜과 알고리듬을 사용해라. 이들을 만들어야 한다면 폭넓은 공개 검토를 하고 반드시 전문적인 보안 분석가들이 문제가 있는지 이들을 검사하도록 해라. 특히 암호학 전문가가 아니고 무엇을 하고 있는지 모르며 알고리듬을 전문적으로 검토하는데 시간을 투자할 계획이 없다면 자신의 암호화 알고리듬을 만들지 마라. 암호화 알고리듬 작성은 전문가들만의 작업이다.
많은 알고리듬은 특허화되어 있어 소유자가 현재 ``자유로운 사용"을 허용한다 하더라도 서명된 계약이 없다면 추후에 이 정책을 늘 변경할 수 있으며 따라서 추후 여러분을 극히 위험한 상황에 놓이게 한다. 일반적으로 모든 특허화된 알고리듬을 피해라 - 거의 모든 경우에 있어 최소한 특허화된 알고리듬만큼 우수하거나 기술적으로 더욱 우수한 특허화되어 있지 않은 접근 방법이 있으며 이를 사용함으로써 많은 법적인 문제를 피할 수 있다.
프로토콜의 경우 SSL (곧 TLS 가 된다), SSH, IPSec, GnuPG/PGP 및 Kerberos 와 같은 표준을 따르는 프로토콜을 사용하려고 해라. 이들 다수는 기능성에서 어쨋든 중복되지만 각자 특수한 용도 (specialty niche) 를 갖고 있다. SSL 은 http (웹) 트랜잭션을 보호하는 기본적인 방법이며 PGP 와 GnuPG 에 구현된 PGP 호환 프로토콜은 이메일 발송인/수취인 (end to end) 을 보호하는 기본적인 방법이다. Kerberos 는 랜상에서 인증을 지원하고 안전하게 하며 공유된 비밀을 입증하는 기본적인 방법이다 (따라서 통신을 실제 보호하기 위한 다른 알고리듬과 함께 사용될 필요가 있다). SSH 는 CVS 접근과 같은 다른 데이타 스트림을 안전하게 하는데도 사용되지만 인터넷을 통한 ``원격 터미널"을 안전하게 하는 기본적인 방법이다 (예, telnet 계열과 X 윈도우 연결). SSH 프로토콜에는 두개의 주요 버전이 있으며 몇가지 키 타입을 선택할 수 있음을 주목해라; 더욱 자세한 정보를 위해서는 관련 문서를 보라. OpenSSH 는 SSH 의 오픈 소스 구현이다. IPSec 는 저수준 패킷과 ``모든" 패킷을 안전하게 하기 위한 기본적인 방법으로 가상 사설망과 원격 머신을 안전하게 하는데 특히 유용하다. 인터넷 프로토콜의 새로운 버전인 IPv6 는 IPSec 가 ``내장"되어 있지만 IPSec 는 일반적인 IPv4 프로토콜과도 함께 작동한다.
다수의 프로토콜들이 많은 다른 알고리듬을 선택할 수 있게 하는데 따라서 알고리듬에 대해 합리적인 디폴트를 선택할 필요가 있을 것이다 (예, 암호화).
암호화 알고리듬 구현의 사용, 수출 및/또는 수입은 많은 나라에서 제한되고 있지만 법은 매우 빠르게 변할 수 있다. 암호학을 사용해 애플리케이션을 구축하려고 하기 전에 규범이 무엇인지 알아내라.
비밀키 (벌크 데이타) 암호화 알고리듬의 경우는 공개적으로 알려져 수년간 공격을 견뎌온 암호화 알고리듬만을 사용하고 이들의 특허 상태를 검사해라. 저자는 Rijndahl 로 알려진 새로운 Advanced Encryption Standard (AES) 를 사용하기를 추천할 것이다 -- 많은 암호학자들이 이를 분석했으며 어떠한 심각한 약점도 발견하지 못했는데 저자는 현재 AES 가 신뢰할 수 있을만큼 충분한 분석을 했다고 생각한다. AES 에 대한 좋은 대안은 Serpent 알고리듬으로 약간 느리지만 공격에 대한 저항성이 우수하다. 많은 애플리케이션의 경우 삼중-DES 는 매우 우수한 암호화 알고리듬인데 이는 꽤 길이기 긴 112 비트 키를 갖으며 특허 문제도 없고 오랫동안 공격에 견뎌왔다 (공개 문헌에 있는 적당한 키 길이를 갖고 있는 다른 암호화 알고리듬보다 더욱 오랫동안 공격에 견뎌왔다). 그러나 삼중-DES 는 소프트웨어에서 구현될 때 매우 느리며 따라서 삼중-DES 는 ``가장 안전하지만 가장 느리다" 고 고려될 수 있다. Twofish 는 우수한 암호화 알고리듬이지만 다소의 오래된 문제가 있다 - Sean Murphy 와 Fauzan Mirza 는 Twofish 가 많은 학자들을 우려하게끔 하는 성질들을 갖고 있음을 보였다 (어느 누구도 어떻게든 이러한 성질들을 악용하는데 사용할 수는 없었다). MARS 는 ``새롭고 참신한" 공격에 대한 저항성이 우수하지만 더욱 복잡하고 소형 기능의 스마트카드에 대해서는 비실용적이다. 우선 저자는 Twofish 를 피할 것이다 - 이는 전혀 악용될 수 없을 것 같지만 이를 확신하기는 어려우며 이러한 문제에 대해 걱정하지 않아도 되는 대안 알고리듬들이 있다. IDEA 는 사용하지 마라 - 미국과 유럽에서 특허화되어 있다. 상수 또는 상수 문자열을 갖는 XOR, ROT (rotation) 스킴, Vinegere 암호 등과 같은 어리석은 알고리듬을 사용하지 마라 - 오늘날의 켬퓨터에서 이들을 해독하는 것은 사소할 수 있다. ``이중 DES" (DES 를 두번 사용) 를 사용하지 마라 - 삼중-DES 가 예방할 수 있는 ``man in the middle" 공격을 당하기 쉽다. 어쨌든 프로토콜은 다수의 암호화 알고리듬을 지원해야 한다; 이렇게 함으로써 한 알고리듬이 해독될 때 사용자는 다른 알고리듬으로 변경할 수 있다.
대칭키 암호화 (예, 벌크 암호화) 의 경우 2016 동안 정보가 비밀로 유지되길 원한다면 90 비트보다 작은 키 길이를 사용하지 마라 (매 18개월의 추가적인 보안을 위해 다른 비트를 추가해라) [Blaze 1996]. 쓸모없는 데이타를 암호화하는 경우는 예전 DES 알고리듬도 상당히 유용하지만 현재 하드웨어 상황에서 brute force 공격을 사용해 DES 의 56 비트 키를 해독하는 것은 너무 쉽다. DES 를 사용하고 있다면 아스키 텍스트 키를 키로 사용하지 마라 - 패리티 (parity) 는 가장 덜 중요한 비트에 있다. 따라서 대부분의 DES 알고리듬은 적들에게 잘 알려진 키값을 사용해 암호화할 것이다. 대신 키의 해시를 만들고 패리티 비트를 정확히 설정해라 (그리고 암호화 루틴으로부터의 에러 보고에 주의해라). 소위 ``수출가능한" 암호화 알고리듬은 단지 40 비트의 유효 키 길이를 갖으며 본질적으로 쓸모없다; 1996년에 공격자는 그러한 키를 12분내에 해독하는데 10,000 불을 쓰거나 또는 이들을 몇일내에 해독하는데 유휴 시간을 사용했을 것이다. 두 경우 모두 매 18개월마다 해독 시간이 절반으로 줄어들었다.
블록 암호화 알고리듬은 ``electronic code book" (ECB) 및 ``cipher block chaining" (CBC) 와 같은 많은 여러가지 모드에서 사용될 수 있다. 거의 모든 경우 CBC 를 사용하고 ECB 는 사용하지 마라 - ECB 모드에서는 동일한 데이타 블록은 스트림내에서 동일한 결과를 반환하며 이는 무엇이 암호화되었는지를 드러내기에 대개 충분하다. CBC 를 포함하여 많은 모드들은 ``초기화 벡터" (initialization vector, IV) 를 필요로 한다. IV 는 보안적일 필요는 없지만 공격자가 예측할 수 없어야 한다. 세션을 통해 IV 를 재사용하지 마라 - 세션을 시작할 때마다 새로운 IV 를 사용해라.
많은 여러가지 스트리밍 암호화 알고리듬이 있지만 많은 알고리듬은 특허 제한을 갖고 있다. 저자는 WAKE 와 관련된 특허 또는 기술적 쟁점에 대해서는 모른다. RC4 는 RSA Data Security Inc. 의 통상 비밀이다; 그후로 누설되었지만 저자는 이의 사용에 대한 실제 법적인 장애물은 모른다. 그러나 RSA 는 이의 사용자들에 대해 법정 소송을 취하겠다고 위협하고 있다 (RSA 가 취할 수 있는 것이 무엇인지는 명확하지 않지만 사용자들을 쓸데없는 법정 소송에서 꼼짝못하게 할 수 있음은 의심할 여지가 없다). RC4 를 사용한다면 이를 의도된 바와 같이 사용해라 - 특히 언제나 생성된 처음 256 바이트를 버려라. 그렇지 않다면 공격당하기 쉬울 것이다. SEAL 은 IBM 이 특허를 낸 것으로 이를 사용하지 마라. SOBER 은 특허화되어 있다; 특허 소유자는 사용 허가를 요청한다면 이를 자유로이 사용할 수 있다고 주장하고 있지만 이는 추후 사용에 대해 장애물이 될 수 있다. 더욱더 흥미로운 것은 블록 암호화 알고리듬이 이들을 스트림 암호로 변환시키는 모드에서 사용될 수 있다는 것인데 스트림 암호를 원하는 사용자는 이 방법을 고려해야 한다 (더욱 공개적으로 얻을 수 있는 알고리듬중에서 선택할 수 있을 것이다).
공개키 암호화의 경우 (서명과 비밀키 전송에 널리 사용되고 있다) 단지 약간의 알고리듬만이 널리 사용되고 있는데 가장 널리 사용되고 있는 알고리듬 중의 하나는 RSA 이다; RSA 의 알고리듬은 단지 미국에서만 특허화되어 있으며 2000년 9월에 만료되어 자유롭게 사용될 수 있다. 공격자가 직접적으로 제공한 원값 (raw value) 을 RSA 를 사용해 절대로 복호화하거나 서명하지 마라. RSA 는 비밀키를 드러낼 수 있기 때문에 결과를 드러낸다 (대부분의 프로토콜은 원값이 아닌 사용자가 계산한 해시에 서명하는 것을 포함하거나 결과를 드러내지 않기 때문에 이는 실제 문제가 되지는 않는다). 절대로 정확히 동일한 원값을 여러번 복호화하거나 서명하지 마라 (원래 값이 노출될 수 있다). 이러한 두 문제 모두 임의의 패딩 (padding, 아무런 의미가 없는, 고정 길이를 갖는 레코드 또는 블록에 무의미한 문자로 채우는 기법) 을 늘 추가함으로써 해결될 수 있다 (PGP 경우와 같이) - 보통의 접근 방법은 Optimal Asymmetric Encryption Padding (OAEP) 라고 불린다.
Diffie-Hellman 키 교환 알고리듬은 두 당사자간에 세션키 일치를 허용하는데 널리 사용되고 있다. 이 자체로는 당사자들이 자신들은 누구이다 라고 말하는 당사자들임을 보증하지 못하며 또한 중개자도 없다. 그러나 수동적인 스니퍼에 대해서는 강력한 보호를 제공한다; 이 특허는 1997년에 만료되었다. 공유되는 비밀을 생성하기 위해 Diffie-Hellman 을 사용한다면 반드시 이를 우선적으로 해시해라 (공유되는 값을 직접적으로 사용하는 경우 공격이 있을 수 있다).
NIST 는 디지털 서명 생성과 입증을 위해 DSS (Digital Signature Standard, 디지털 서명 표준) 을 개발했다 (이는 ElGamel 암호화 시스템을 수정한 것이다); 이것이 개발된 조건중의 하나는 특허에 자유롭다는 것이였다.
RSA, Diffie-Hellman 및 El Gamel 기법은 일반적인 대칭키와 비교해서 동일한 보안을 제공하기 위해 키에 대해 더욱 많은 비트를 필요로 한다; 이러한 시스템에서 1024 비트 키는 대략 80 비트 대칭키와 동등한데 저자 의견으로는 이것이 오늘날 사용해야 하는 최소 길이이다. 공개키에 대해 매우 작은 비트를 필요로 한다면 타원 곡선 (elliptic curve) 암호화를 사용할 수도 있다 (IEEE P1363 에 다소의 제안된 곡선이 있는데 이러한 곡선을 찾아내는 것은 어렵다). 그러나 주의해라 - 타원 곡선 암호화는 특허화되어 있지 않지만 어떤 고속화 기법은 특허화되어 있다 (타원 곡선은 흔히 사용되는 세션 암호화/벌크 암호화 키 등에는 이러한 속도화가 실제 필요치 않을 만큼 충분히 빠르다).
어떤 프로그램들은 일방향 해시 알고리듬, 즉 임의의 데이타들 취해 공격자가 되돌리기 어려운 고정된 길이의 숫자를 생성하는 함수를 필요로 한다 (예, 공격자가 동일한 값을 생성하는 여러 데이타셋을 생성하는 것은 어렵다). 여러해 동안 MD5 가 선호되었지만 최근의 연구는 MD5 의 128 비트 길이가 충분하지 않을 수도 있으며 [van Oorschot 1994] 어떤 공격이 MD5 의 보호를 무력화 시킴을 보였다 [Dobbertin 1996]. 정말로 최고 산업계 암호학자가 MD5 를 해독했지만 종업원 협약에 의해 어쩔 수 없이 기밀로 유지되고 있다는 소문이 있다 (John Viega 가 게시한 2000년 8월 22일 Bugtraq 를 보라). 누군가 소문을 만들 수도 있지만 해독될 수 있다는 생각을 그럴듯하게 만든 충분한 약점이 발견되었다. 새로운 코드를 작성한다면 MD5 대신 SHA-1 을 대신 사용해라. 원래의 SHA (현재 ``SHA-0" 로 부른다) 를 사용하지 마라; SHA-0 는 MD5 가 갖고 있는 몇몇 약점을 갖고 있다. 해시 알고리듬에 더욱 많은 비트를 필요로 한다면 SHA-256, SHA-384 또는 SHA-512 를 사용해라; NIST FIPS PUB 180-2 에서 스펙을 얻을 수 있다.
통신할 때 어떤 종류의 무결성 검사가 필요하다 (암호화에만 의존하지 마라. 공격자가 정보를 ``임의의" 값으로 변경할 수도 있다). 해시 알고리듬을 사용해 무결성 검사를 할 수 있지만 단지 해시 함수를 직접적으로 사용하지는 마라 (이는 사용자를 ``확장" (extension) 공격에 노출시킨다 - 공격자가 해시값을 사용해 자신들의 데이타를 추가한 후 새로운 해시를 계산할 수 있다). 보통의 방법은 ``HMAC" 로 다음과 같이 무결성 검사를 수행한다.
H(k xor opad, H(k xor ipad, data)). |
H 는 해시 함수 (일반적으로 MD5 또는 SHA-1) 이고 k 는 키이다. 따라서 무결성 검사는 대개 HMAC-MD5 또는 HMAC-SHA-1 이다. MD5 가 약간의 약점을 갖고 있지만 저자가 아는한 MD5 는 위와 같이 사용될 때 취약하지 않으며 따라서 (저자가 알기에) HMAC-MD5 도 취약하지 않음을 주목해라. 이는 IETF RFC 2104 에 세부적으로 정의되어 있다.
HMAC 방법에서 송신자와 같이 수신자도 동일 데이타를 변조할 수 있음을 주목해라. 이는 대개 문제가 되지 않지만 피해져야 한다면 공개키 방법을 사용하고 송신자에게 자신의 비밀키로 데이타에 서명하게 해라 - 이는 이러한 변조 공격을 예방하지만 더욱 많은 비용이 들며 대부분의 환경에서 필요하지는 않다.
중요한 데이타는 암호화와 무결성 검사 모두를 해야한다. 무결성을 제공하는 암호화에 의존하지 마라 - 공격자가 비트를 다른 값으로 변경할 수도 있으며 공격자 이를 특정 값으로 변경할 수 없더라도 단지 값을 변경시키는 것만으로 충분할 수도 있다. 일반적으로 어떤 미묘한 공격을 예방하기 위해 무결성과 비밀에 다른 키를 사용해야 한다.
대개 충분히 논의되지 않는 한가지 문제는 ``트래픽 분석" 문제이다. 즉, 메시지가 암호화되어 해독되지 않더라도 적은 암호화된 메시지로부터 매우 많은 것을 알 수 있다. 예를 들어 두 회사의 사장이 많은 암호화된 이메일 메시지를 교환하기 시작한다면 두 회사가 합병을 고려하고 있다고 생각할 수도 있다. 다른 예로는 많은 SSH 구현은 패스워드를 교환하는데 있어 약점을 갖고 있다고 알려져 있다; 관측자는 패킷을 보고 패스워드 자체는 알아낼 수 없더라도 패스워드의 길이 (또는 길이 범위) 는 결정할 수 있다. 또한 패스워드를 해독하는데 상당히 도움이 되는 패스워드 관련 다른 정보를 정할 수도 있다.
반드시 어느 정도 해독하는 것을 가능하게 하지 말고 (신뢰되어지는) 신뢰 환경이 변할 때 다른 키를 사용해라. 너무 오랫동안 동일한 키를 사용하지 마라 - 얼마 후에 세션 키 또는 패스워드를 변경해라. 따라서 적은 이들의 해독을 다시 시작해야 할 것이다.
일반적으로 암호화할 것을 압축해야 한다 - 이는 고정된 헤더를 추가해 별로 좋진 않지만 암호화된 결과를 더욱 작게 만들뿐아니라 메시지에 존재하는 많은 패턴을 제거한다. 따라서 압축을 통해 결과가 더욱 작아진다면 보통 ``이익" 으로 간주되었다.
관련해서 주목할 것은 자신의 고유 통신 프로토콜을 만들어야 한다면 이전에 무엇이 진행되어 왔는지의 문제를 조사해라. Bruce Schneier [1998], Mudge 의 breaking of Microsoft's PPTP implementation 및 후속 작업 뿐만 아니라 TCP/IP 프로토콜 스위트에서 보안 문제에 대한 Bellvin [1989] 의 검토와 같은 고전이 도움이 될 것이다. 물론 반드시 모든 새로운 프로토콜을 광범위하게 공개적으로 검토해야 가능한 재사용해라.