상세 컨텐츠

본문 제목

7 보안 메카니즘

프로그래밍

by 라제폰 2008. 12. 1. 21:18

본문

7 보안 메카니즘

in English

이 장에서는 IT 보안을 구현하는 데 사용되는 대표적인 메카니즘에 대해 개략적으로 말한다. 거론되는 메카니즘은 암호, 접근통제 리스트, 인증, 규칙 및 정책 구현, 그리고 가용성 메카니즘이다.

7.1 암호 및 전자서명

도입


암호 는 키를 이용하여 정보(평문)를 코드화된 형태(암호문)로 변환하는 것이다. 암호는 대부분 정보의 비밀성을 보호하기 위해 사용된다. (즉, 정보에 접근할 수 있는 사람을 제한)
강력한 암호시스템에서는, 복호화 키를 이용해서만 원래의 정보(평문)를 복구할 수 있다. 따라서 평문 정보는 "엿보는 시선"으로부터 보호되는 것이다. 강력한 암호화 알고리듬이란 현재의 슈퍼컴퓨터로(즉, 10년후의 PC) 쉽게 뒤집어질 수 없는 것이다. 암호에는 공용 키 및 공개 키 암호의 두가지 주요 방식이 있다.

암호 참고:

암호에 대한 참고서는 [crypto1].
www.cs.hut.fi/crypto/                                        [암호 SW에 대한 포인터]
ftp.funet.fi/pub/crypt                                          [탁월함: "꼭 가봐야 할 곳"]
www.counterpane.com/                                 [Schneier: Blowfish, Twofish]
ftp.psy.uq.oz.au/pub/Crypto/                          [E.Young's DES, SSL]
www.systemics.com/                                      [cryptix Java, C, Perl]
www.eskimo.com/~weidai/cryptlib.html          [Wei Dai's C++ lib]
www.cs.hut.fi/ssh/                                           [Tatu Ylonen's SSH]
cwis.kub.nl/~frw/people/koops/lawsurvy.htm   [암호+법]
ftp://ripem.msu.edu/pub/crypt/sci.crypt/ -- sci.crypt Archives
www.swcp.com/~iacr/ -- International Association for 암호학적 연구
www.cs.adfa.oz.au/teaching/studinfo/csc/lectures/classical.html    고전적인 암호 해설
www.cryptosoft.com/snews/snews.htm            [암호관련 뉴스기사들에 대한 색인]

Securityportal에 저자가 쓴 기사: 국제적으로 사용할 수 있는 강력한 암호 제품들 in September 1999.

키 길이에 대한 논의:
www.counterpane.com/keylength.html   (published January 1996)
Byte May 1998 에 실린 훌륭한 기사, by Bruce Schneier [crypto2].
www.ssh.fi/tech/crypto/intro.html

7.1.1 공용 (또는 대칭) 키 암호

데이타를 교환하는 양쪽 모두 키 를 가지고 있는데, 이 키는 (다른이들은 모름) 한쪽 편에서는 전송전에 데이타를 암호화하는 데, 다른쪽에서는 수신시 복호화하는 데에 쓰인다. 대칭 암호문에는 두가지 종류가 있다: 블록 (한번에 데이타 블록을 암호화) 과 스트림 암호문 (각각의 bit/byte 또는 단어를 순차적으로 암호화). 견본 알고리듬으로:

  • 잘 알려진 DES (Data Encryption Standard)는 공용 키 블록 암호문이다. DES는 NIST (National Institute of Standards and Technology)와의 계약에 따라 IBM에서 만들었다. 기본 모드에서는 64-bit 블록의 평문을, 56 bit의 키로, 테이블 조회와 비트 재배열의 복잡한 조합에 대한 16번의 반복을 이용하여 암호화된다.
    • 미국 정부는 1977년에 DES를 인증했고 (1981에 ANSI 표준이 됨) 5년마다 DES를 재인증하고 있다. 컴퓨팅 하드웨어의 발달로, 현재 상당한 자원을 가진 큰 조직들에서는 DES를 깰 수 있다. ( brute force 방법으로: 가능한 모든 키 조합을 시도하는 것). 이는 대부분 DES가 상대적으로 작은 56 bit의 키 길이를 사용하기 때문이다.
    • 하나의 해결책은 소위 Triple-DES 또는 3DES 시스템이라는 것으로, 데이타 블록이 (두)세 개의 서로 다른 키를 사용하여 (두 번 내지) 세 번 암호화 되는 것이다. (정상적 암호화의 3배보다는 조금 더 빠른 시간내에). 3DES는 대략 112 bit 에 상당하는 키 강도를 가진다. 3DES는 아직 미국정부의 인증을 받지못했으나, 최초의 DES가 재인증 될 것 같지는 않다.
    • DES에서 쓸 수 있는 “동작모드” 는 몇가지가 있는데, 이들은 Electronic Codebook (ECB), Cipher Feedback (CFB) 와 Cipher Block Chaining (CBC) 이다. 미국정부는 가장 약한 모드인 ECB는 사용하지 말 것을 권고하고 있다. 유감스럽게도 많은 상용 암호화 제품들은 ECB 모드를 사용한다.
    • DESX는 DES를 상당히 강화한 변형이다 (RSA Faq 참조).
  • RC2는 RSA사에서 만든 블록 암호문으로, 1996년 인터넷에 발표되기 전까지는 통상 기밀이었다. 이것은 상당히 강력한것으로 보이며 키 길이를 40 에서 255 bit (또는 2048 bit??) 까지 허용한다.
  • RC4, RC5 는 (독점권이 있는) 가변 키 길이의 스트림 암호문으로, RSA사에서 1994년에 만들었다. 키 길이가 가변적이므로 DES보다 더 안전할수도 있고 못할 수도 있다. < 미 수출관리국은 대략 40-bit 키길이의 버전을 승인했다. 자국내 버전은 40에서 1024 bit 사이의 키를 가질 수 있다 >.( => 현재는 키 길이 제한이 없어짐:역주). RC4가 가장 빠르고 (RSA 승인없이 인터넷 초안으로 발표되기도 했다 -1994년, "ARCFOUR" 이라고 불림) RC5 가 가장 "안전한" 것으로 간주된다.
  • IDEA: 취리히에 있는 스위스 ETH 대학과 Ascom 이 개발했다 (특허권있음). 1990년에 발표되어 1992년 Lai & Massey가 완결했으며, 128 bit 키를 사용한다. 이 알고리듬에서는 아직까지 발견된 취약점이 없으며, brute-force 공격은 가까운 장래에는 성공하지 못할 것이다. Ascom Tech AG. 가 특허권을 가지고 있다. 라이센스 조건은 기본적으로: 개인적 사용은 무료이고 판매할 수 있는 제품에 IDEA를 합치는 것은 비용이 든다. PGP는 대칭 알고리듬에 IDEA를 사용한다.
  • Blowfish: 공개 알고리듬으로, ( Bruce Schneier 가 개발 www.counterpane.com/blowfish.html ) 비교적 새로운 것이지만(1993) 중대한 취약점은 나타나지 않았다. 작고 빠르며, 키길이는 가변적이다.(32-448 bits, 일반적으로 128 또는 256 bit). 8 byte 블록을 사용하고 32 및 64bit 프로세스에 최적화 되어 있다.
  • AES(Advanced Encryption Standard)는 DES를 대체하기 위해 설계되었다. < NIST는 1998년 6월 까지 제안을 받는다. 128,192,256 bit의 키 길이를 가지고 128 bit 블록을 사용해야 한다. 최종 알고리듬은 2000년까지는 나오지 않을 것 같다. > (=> 현재 5개의 후보를 놓고 최종 심사작업중이다: 역주. csrc.nist.gov/encryption/aes/ ) Schneier는 128 bit 블록에 16 라운드 블록 암호문인 공용 Twofish를 제안했는데, Blowfish보다 빠르고 자원이 적게 든다 (스마트 카드에서도 돌아감). www.counterpane.com/twofish.html 참고.
  • CAST 는 Northern Telecom (Nortel)의 Carlisle Adams 와 Stafford Tavares 가 만든 것이다. Nortel은 CAST를 위한 특허를 출원했으나, 이들은 CAST를 누구나 사용료없이 사용할 수 있게 하기로 서약했다. CAST는 취약하거나 약간 취약한 키도 가지지 않는다. 선형 및 미분 암호해독은 발표된 것 중 가장 강력한 암호해독 형태들로서, DES를 깨는데 모두 효과적이었는데, CAST가 이 두가지 모두에 대해 완벽한 면역성을 가지고 있다는 강력한 논쟁이 있다. CAST는 나온지 얼마 안되었기 때문에 기록이 길지 않지만, 정형화된 설계와 설계자들에 대한 좋은 평판으로 의심할 여지 없이 주목을 끌 것이고 다른 암호학계 사람들의 암호해독 공격 시도가 있을 것이다.

이점: 공용 키 알고리듬이 비슷한 수준의 공개 키보다 훨씬 빠르다.
단점: 양쪽이 같은 키를 알고 있어야 하므로 이를 교환하기 위한 안전한 방법을 찾아내야 한다. (별도의 안전한 채널을 통해).

대표적인 응용프로그램: 비밀성을 보호하기 위한 정보 암호화. 즉 데이타 파일의 로컬 암호화 (전송이 필요없는), 데이타 세션 암호화, 은행거래시스템 (PIN 암호화).

7.1.2 공개키 암호

양쪽 모두 비밀 키 와 공개 키 를 가지고 있다. 비밀키는 각 소유주만 알고있지만, 공개 키는 누구에게나 사용 가능하다 (전화번호처럼). 보내는 쪽은 수신자의 공개키를 가지고 메시지를 암호화하고, 수신자는 자기의 비밀키로 복호화 한다. 이것은 암호화와 복호화에 서로 다른 키를 쓰는 알고리듬이 개발될 수 있다는 Diffie 와 Hellman의 발견으로 가능해졌다 (Stanford 대학교에서, 1975 년 가을). 공개키과 비밀 키가 모여 키 쌍을 이룬다.
다음의 공개키 시스템들이 잘 알려져 있다:

  • RSA (고안자인 Rivest, Shamir 와 Adleman의 이름을 따서) 알고리듬은 1977년 MIT에서 개발되었고 현재 사용되는 가장 일반적인 공개키 시스템이다. RSA 사에서는 최소 768 bit의 키 길이를 가지는 키를 권고한다. RSAREF 는 RSA에서 만든 라이브러리로 많은 상용제품과 공개용 제품(PGP 미국판 같은)에 들어가 있다. RSA 호환 국제적 공개용 라이브러리들(큰 키 크기를 가진)도 있으며 SSH 같은 제품에서 사용된다.(SSH는 디폴트로 1024 bit 키를 사용한다). RSA는 키 생성이 확인보다 느리다. RSA 는 2000년 9월 20일까지 미국에 특허가 있었다.
  • Diffie-Hellman (역시 고안자의 이름을 따서) 키 교환 프로토콜은 1976년 발표되어, 안전하지 못한 네트웍을 통해 공공연하게 알려진 정보로부터 공용 비밀키들을 만들어 낸다. 이 공용 키들은 세션 키를 만드는 데 이용될 수 있다. 그 강도는 "이산 로그 (descrete logarithm) " 문제에 기반을 둔다. 양쪽이 인증되지 않았으므로, "중간자(man in the middle)" 공격에 취약하며, 이는 추가적인 프로토콜, 즉 전자서명 프로토콜의 사용으로 예방할 수 있다. (e.g. the Authenticated DH key agreement protocol, 1992년 Diffie, Oorschot 와 Wiener 발표).
    Sun 에서는 Secure RPC와 SKIP에서 이 알고리듬을 광범위하게 사용한다.
    이 알고리듬은 1997년 특허권이 만료되어 부가적인 이점을 가진다.
  • ElGamal 공개 키 시스템은 (Taher ElGamal 고안) 암호화와 서명 알고리듬 두가지 모두로 이루어진다. Diffie-Hellman 키 교환과 비슷하고 그 강도는 "이산 로그 (descrete logarithm) " 문제에 기반을 둔다. 키 길이의 강도는 RSA와 비슷하다. 이것은 꽤 느리고, 뛰어난 난수발생을 필요로 한다. DSA 는 서명 알고리듬을 기반으로 한다.
  • DSS는 전자서명 표준(Digital Signature Standard)으로 , 미국 정부(NIST & NSA)가 1994년 5월 전자인증 표준으로 승인한 DSA (Digital Signature Algorithm)를사용한다. DSA 는 EIGamal과 Schnorr의 암호 알고리듬을 기반으로 한다. 서명 생성이 확인보다 빠르다. (이는 드문경우로, 생성보다 확인이 더 많을 듯하다). DSA는 키 교환 메카니즘이 없고, 새롭고, 선정작업에 NSA가 깊이 관여한데다 공개 검토에 제출되지 않았기 때문에 비판을 받아왔다.

특허: 위의 RSA와 DH는 미국 특허권이 있다. Sunnyvale의 PKP (Public Key Partners)는, CA가 허가권을 가지고 있다. 그렇지만 DH 특허는 현재 만료되었고(19.8.97) RSA 특허는 (미국에서만 유효) 20.9.00.까지만 유효하다 (만료됨). DSS에 영향을 주는 특허 두개가 2008년까지 유효하다 (Scnorr 와 Kravitz의).
강도: 공개키 알고리듬은 풀기 어려운 수학적 문제에 의존한다. 예를들면 유한체 (finite field)에 대한 로그를 취한다든지(Diffie-Hellman) 큰 숫자를 소인수분해하여 (RSA) 단방향 기능 을 생성하는 것이다. 이러한 기능들은 한 방향으로 계산하는 것이 반대방향 계산보다 훨씬 쉬워, brute force 복호화를 사실상 불가능하게 만든다 (적절한 키 크기를 썼을 때, 현재의 컴퓨팅 능력으로는).
타원형 곡선 과 혼합체 발생기 (e.g. RPK at www.rpk.co.nz ) 등과 같은 더 새로운 기술에서는 더 빠른 공개키 시스템을 약속하고 있다.

PK의 이점: 비밀키만 비밀을 유지하면 된다. 공개키만 교환하면 되므로 키교환을 위해 별도의 안전한 채널이 필요하지 않다. 하지만 공개키가 송신자에게 전달될 때에는 그것이 올바른 공개키라는 것을 절대적으로 확신할 수 있는 방법으로 되어야 한다! 공개키 암호 또한 전자 서명 을 위한 방법을 제공한다.
단점: 알고리듬의 수학적 복잡성 때문에 속도가 느리다.

대표적인 응용프로그램: 발신지 증명 보장, 수신자만이 정보를 복호화 할 수 있도록 보장, 대칭 세션 키 전송.

7.1.3 해쉬 / 메시지 축약

해쉬 기능은 한 블록의 데이타로부터 고정길이 문자열을 만들어 낸다. 기능이 단방향인 경우, 메시지 축약 기능이라고도 불린다. 이 (빠른) 기능들은 메시지를 분석하여 일정한 길이의 사실상 유일한 축약을 만들어낸다. 즉 동일한 해쉬를 가지는 메시지를 찾는다는 것은 매우 빠른 컴퓨터로도 거의 불가능하다. 동일한 축약을 가지는 또다른 메시지를 만들어내는 실현 가능한 방법은 알려지지 않았다. 이러한 알고리듬들은 일반적으로 무결성 확인을 위한 메시지 서명을 생성하는 데 사용된다.

  • MD2, MD4 및 MD5는 RSA사의 Ron Rivest가 개발한 해쉬 기능들이다. 이들은 모두 128-bit 축약을 만들어 낸다. MD2 가 가장 느리고, MD4가 가장 빠르며, MD5는 MD4 보다 좀더 보수적으로 설계되었다. 둘다 공개적으로 사용가능하다.
  • MD5 알고리듬은 사실상의 축약을 위한 해쉬 표준이다. 대부분의 플랫폼에 대해 인터넷에서 공개버전을 사용할 수 있으며 무결성 검사시스템에 널리 사용되고 있다. 하지만 1996년 5월, 몇가지 취약점이 독일 정보보안국의(German Information Security Agency) Dr. Hans Dobbetin 에 의해 발견되었다. www.cs.ucsd.edu/users/bsy/dobbertin.ps 참조.
  • SHA-1 (Secure hashing algorithm) 은 NIST 가 후원하는 해쉬 기능으로 미국정부가 표준으로 받아들였다. 160-bit 의 해쉬를 생성하며 (즉 MDx보다 큰) MD5보다 대략 25% 더 느리다. MD5보다 SHA-1이 권장된다 .
  • Ripe-MD-160 은 유럽공동체로부터 나온 알고리듬이다.

이점: 암호화보다 훨씬 빠르고 결과가 고정길이를 가진다 (따라서 아주 큰 파일이라도 동일한 크기의 축약을 만들어내므로, 데이타 전송시 훨씬 효율적이다).
단점:

  • 무결성만을 보장한다.
  • 알려진 취약점: B. Preneel 와 P.C. van Oorschot 의 기사, "On the Security of Two MAC Algorithms", Advances in Cryptography- EUROCRYPT '96, Saragosa, Spain, 1996년 5월. 알려진 MD5 envelope 방법(RFC1828)과 은행거래 표준 MAA (ISO 8731-2) 에 대한 위조 공격에 대응하는 몇가지 개선점을 보여준다.

대표적인 응용프로그램: 많은 인터넷 서버들은 다운로드 받을 수 있게 돼 있는 중요한 파일들에 대해 MD5 축약을 제공한다. 대부분의 전자 서명 시스템과 안전한 이메일 시스템은 무결성 보장을 위해 축약 기능을 사용한다.

해쉬의 흥미로운 변형으로 메시지 인증 코드 Message Authentication Codes (MAC)가 있는데, 키를 가지는 해쉬 기능이다. MAC을 생성하거나 확인하기 위해서는, 키를 가지고 있어야 한다. 이것은 해쉬가 전송 도중 변경되지 않았다는 것을 입증하는데 유용하다. 두가지 예로 HMAC (RFC 2104) 과 NMAC이 있으며, SHA-1을 기반으로 한다. 

7.1.4 암호 적용

PGP, S/MIME, Secure RPC (따라서 secure NFS & NIS+ 도) 및 SKIP 과 같은 응용프로그램들은 부인 방지와 비밀성을 보장하기 위해 공개키 암호와 대칭키 암호를 조합해서 쓴다. (빠른) 서명 생성을 위해서는 해쉬 알고리듬이 사용된다.

  • 대부분의 암호화 시스템에서 주된 문제는 어떻게 키를 분배하고 관리하느냐이다. 많은 시스템들은 수동적인 키-링 관리를 필요로 한다. 아래의 "인증 기관" 참조.
7.1.4.1 암호화 강도

암호 시스템에는 몇가지 가능한 취약점들이 있으며, 시스템의 강도는 가장 약한 링크의 강도이다.

  • 대칭 또는 비밀키의 비밀성 정도
  • 키 추측 또는 모든 가능한 키 시도의 어려운 정도. 키 길이가 알고리듬의 암호화 강도를 결정한다. 모든 암호 알고리듬들은 "brute force" 공격 (가능한 모든 키 조합을 시도하는) 에 취약하다 .
  • 잘못된 구현:
    • 암호화 엔진에 사용되는 "의사" 난수 발생기가 (너무) 예측 가능할 수 있다. 적어도 암호화 키를 추측하는 것 만큼은 어려워야 한다.
    • 알고리듬이 부정확하게 구현될 수 있다.
    • 백도어가 존재할 수 있다.
  • 잘못된 설계:
    • 어떤 알고리듬들은 쉽게 뒤집어 진다 (분석 및 파괴가 쉽다), 가령 WinWord, Pkzip, WordPerfect 등등.
    • 발표되지 않고 peer review 에 제출되지 않은 알고리듬들은 강력한 것으로 간주되어서는 안된다. " 모호함을 통한 보안" 은 결연하고 재정적 능력이 있는 공격자에게는 방어물이 되지 못한다.
    • 알려진 평문 공격(Known Plaintext Attack): 많은 알려진 문장들을 암호화하여 결과를 분석하면, 알고리듬이 어떻게 작동하는지 추측 가능할 수도 있다.
  • 수학은 해마다 발전한다. 따라서 새로운 수학적 개념이 기존의 암호 시스템을 약화시킬 수도 있다 (실례로 최근의 선형 및 미분 암호해독이 있다). 현재 공개 키 (PK) 시스템의 강도는 수학적 인수분해와 이산 로그 문제의 난이도를 기반으로 한다. 이 문제들을 푸는 보다 빠른 수학적 방법이 발견될 수도 있으며, 그렇게 되면 PK 추측이 쉬워진다.

다음 논의는 키 길이에 대한 문제에 초점을 두고 있지만, 위의 문제들이 다루어지지 않고는 강력한 키도 아무 소용이 없다!

컴퓨터는 해마다 점점 빨라지고, (계산능력은 2년마다 배가 된다), 저렴해지고 네트웍도 좋아지고 있다. 모든 암호 알고리듬들은 "brute force" 공격(가능한 모든 키 조합을 시도하는) 에 취약하다.

대칭(또는 공용)키 알고리듬:
일반적으로 키 길이가 알고리듬의 암호화 강도를 결정하는데, 대략 2의 키 길이만큼의 거듭제곱 정도의 공식으로 된다.따라서 56 bit 키를 깨는 데는 40 bit 키를 깰 때보다 65,536 배의 시간이 더 걸린다.

대부분의 제품들은 미국에서 나오고 미국 수출규제를 받는다.

  • 30 bits 는 좋은 PC에서 "brute force" 로 추측할 수 있다.
  • 40 bits:
    • 1995년, 프랑스의 학생 Damien Doligez가 40bit 넷스케이프 공용 암호화 키를 120대의 유닉스 시스템으로 이루어진 네트웍을 이용하여 8일만에 성공했다. (brute force 로: 가능한 모든 키 조합을 시도).
    • 1996년에는, 개선된 알고리듬에 의해 4시간만에 무너져 버렸다.
  • 56 bits:
    • 1997년, 56 bit DES 키가 전용칩(programmable gate arrays)에 의해 3주안에 깨질 수 있고, NSA와 같은 정보조직에서는 수초안에 깰 수 있다.
    • 1999년 초, 22 시간 걸림. www.eff.org/pub/Privacy/Crypto_misc/DESCracker/HTML/19990119_deschallenge3.html
    • 소문에 의하면 NSA 몇 년 전부터 DES를 1-2초안에 깰 수 있는 시스템을 가지고 있다고 한다.
  • 64 bits: 정부 및 막강한 조직들에서는 깰 수 있을 것이다.
  • 80 bits: 현재로서는 깨기 힘들 것?
  • 128 bits: 50년 이내에 깨기 힘들것?

공개(비대칭)키 알고리듬:

  • 공개키 시스템은 전자서명 및 부인방지에도 사용되고 거의 변하지 않으므로, 키 강도가 더욱 중요하다.
  • 공개키가 아닌 비밀키를 추측하는 것이 문제이므로 공개키들은 대칭키보다 더 길다. RSA 알고리듬에서 이것은 두 개의 큰 소인수를 가지는 큰 정수를 인수분해하는 것과 같다. RSA는 얼만큼의 키 강도가 필요할까? 다음은 http://www.ssh.fi/tech/crypto/intro.html 에서 인용한 것이다:
    • 256 bit 계수는 평범한 사람들도 쉽게 인수분해한다.
    • 384 bit 키는 대학 연구그룹이나 기업에서 깰 수 있다.
    • 512 bits 는 주요 정부들의 손에 미친다.
    • 768 bit 키는 장기적으로 봤을 때 안전하지 못할 것이다.
    • 1024 bits 나 그 이상은 인수분해에 중대한 알고리듬의 발전이 없다면 현재는 안전할 것이다.
    • 2048 bit 키는 많은사람들이 십년간은 안전할 것이라고 생각한다.

키 크기에 대한 권고: 어느 정도가 강력한가 ?

암호화 키 크기는 다음을 토대로 선택되어야 한다:

  • 누구로부터 정보를 보호하고 싶은가 (공격자에게 가능한 자원).
  • 공격자가 암호화된 정보를 얻는 것이 얼마나 쉬운가, e.g. 전송 네트웍이 얼마나 안전하지 못한가 (인터넷을 통한 정보 전송은 당연히 지역 서브넷에서보다 더욱 보호가 필요하다).
  • 정보가 얼마나 오래 보호되어야 하는가. 데이타를 전혀 보호하지 않는 것 보다는 약한 암호화라도 쓰는 것이 더 낫지만, 약한 암호화 시스템의 위험은 사용자들에게 잘못된 보안 감각을 줄 수 있다는 것이다.

공격자
기간
권고 키 크기

호기심 많은 해커
정보가 며칠동안 보호되어야 한다.
공개키 512 bits
공용키 40 bits

호기심 많은 해커
정보가 최소 2년동안 보호되어야 한다.
공개키 1024 bits
공용키 60 bits

큰 조직
정보가 최소 20년동안 보호되어야 한다.
공개키 1568 bits
공용키 90 bits

정부
정보가 최소 20년동안 보호되어야 한다.
공개키 2048 bits
공용키 128 bits

여기서 강력한 암호화라는 것은 다음보다 크거나 같은 키크기를 사용하는 것으로 정의하도록 하자:

공개키 1568 bits (for RSA, DH and ElGamal)
공용키 90 bits

타원형 곡선이나 Quantum Cryptography 같은 새로운 암호화 시스템에 대해 어느 정도가 "강력한"지 여기서는 아직 정하지 않았다.

위의 참고 부분을 참조한다.

7.1.4.2 법적문제 / 수출규제

여기 전세계에 걸친 암호관련 법률과 규제에 대한 "국제법 암호 조사" 가 있다: cwis.kub.nl/~frw/people/koops/lawsurvy.htm.이것은, 특히 99년 9월이후로, 빠르게 변하고 있다.

* 다음 [] 부분은 현재 바뀐 부분이 많기 때문에 번역하지 않고 원문만 그대로 둡니다.-역자

[The U.S. and certain other countries consider encryption to be a weapon and strictly control exports. This is basically crippling the efforts to include encryption in Applications, Internet services such as Email and Operating systems.

In general the U.S. allows export of 40bit shared key systems and 512 bit Public Key systems.

  • Exceptions: There have been some exceptions to this rule, such as export to Canada & Australia and to large financial institutions world-wide.
  • Lotus export Notes with a 64bit key, of which 24bits are escrowed with the U.S. Govt., making more difficult for non U.S. agencies to look at your Notes communications!
  • Certain products may be used by U.S. companies outside the U.S.
  • Vendors have started building Interfaces into which strong encryption products can be plugged, assuming they're available internationally. E.g. Eudora Pro has a Plugin API which could allow seamless integration strong international encryption unit, without break U.S. law. Other examples are Sun (Solaris DES & Diffie Hellman libraries), Microsoft (NT Secure API), Qualcomm (Eudora Pro + PGP), various PGP Plugins and GUI's.

Some countries (e.g. France), forbid encryption except when a key has been deposit in an escrow (so the legal authorities can listen to all communications if they need).

Other countries allied to the U.S. (e.g. Germany, UK, Sweden, etc.) also enforce the U.S. restrictions by allowing strong encryption domestically, but restricting export of cryptographic devices.

The OECD made a set of recommendations on international cryptography in June 1997, see www.oecd.org/dsti/iccp/crypto_e.html . Many countries have almost no restrictions, but some (especially European) countries are considering some kind of restriction of the use of cryptography in the future.

The only strong encryption software widely available internationally, known to the author of this document, are from Australia, Finland, Ireland and Russia. ]

7.1.4.3 디지탈 Time-stamping 서비스 (DTS)

DTS는 전자 문서에 대해 안전한 timestamp를 발행한다.

  • (발신자의) 문서에 대한 메시지 축약이 생성되어 DTS에 전송된다. DTS는 timestamp와, timestamp가 수신된 날짜와 시간 및 DTS의 안전한 서명을 돌려 보낸다. 문서의 내용은 DTS에게 알려지지 않는다 (축약만 알려짐).
  • Timestamp는 여러 해 동안 필요할 것이므로, DTS는 아주 긴 키를 사용해야 한다.
7.1.4.4 인증서, 인증기관 (CA), PKI 그리고 신뢰된 제삼자 (Trusted Third Parties,TTP)

인증서는 개인의 신원에 대해 그의 공개 키를 증명해 주는 전자문서이다. 이들은 특정 공개키가 실제로 추정 소유자에게 속한다는 것을 확인하도록 해준다. ISO 인증서 표준은 X.509 v3 이고 구성요소는: 주체의 이름, 주체의 특성, 주체의 공개키, 유효일, 발행자 이름, 인증서 일련번호 및 발행자 서명이다. X.509 의 이름들은 X.400 메일 주소와 비슷하지만 인터넷 이메일 주소를 위한 필드를 더 가진다. X.509 표준은 S/MIME, SSL, S-HTTP, PEM, IPsec 키 관리에서 사용된다.

LDAP (Lighweight Directory Access Protocol) 은 X.500 기반의 인증서 관리를 위한 디렉토리 서비스이다. PGP5와 같은 어떤 보안 이메일 제품들에는 LDAP 서버 질의와 갱신을 지원하는 기능이 내장되어 있다.

인증서는 인증기관 (CA) 에 의해 발행된다. CA는 신뢰된 기관이며, 사용자의 신원을 입증한다. CA는 신뢰할 수 있는 공개키를(즉, 아주 큰) 가지고 있어야 하며 비밀키는 매우 안전한 장소에 보관해야 한다. CA들은 계층 구조를 이룰 수 있으며, 이 때 낮은 수준의 CA는 높은 CA를 신뢰한다.

송신자와 수신자가 자기의 통신상대방을 절대적으로 확신할 수 있어야 하는 상황에서는, CA가 그런대로 괜찮은 솔루션이다. CA의 또다른 이름은 신뢰된 제삼자(TTP, Trusted Third Party). 양쪽이 모두 공통된 기관을 신뢰한다면, 이 기관은 양측의 신임장을 확인하는 데 이용될 수 있다. E.g. 송신자가 자기의 공개 키, 이름 (및 다른 확인 정보) 을 CA에게 보낸다. CA는 이 정보를 할 수 있는 데까지 입증하고, 패킷에 자기의 각인을 덧붙여 수신자에게 보낸다. 수신자는 이제 송신자가 직접 자기가 누구라고 하는 것 보다 더 확신할 수 있다.

CA의 문제점은 이들을 믿어야 한다는 것이다! 그러나, 은행들 마저도 전세계적 금융 거래 네트웍인 SWIFT를 구현함으로써 그 문제를 극복했다.
다음을 참조한다:

7.1.4.5 비상시 파일 접근

암호화를 이용해 파일의 기밀성을 보호할 때 빈번한 요구사항중 하나가 비상시 파일 접근 (Emergency File Access) 이다. 파일 소유주가 중요한 파일을 암호화 해놓고 키를 잊어버리면 어떤 일이 일어나는가? 두번째 키가 생성되고, 다섯 부분으로 나뉘어져 다섯 (부분) 키 중 어느 두 개라도 조합하면 복호화 키로 사용할 수가 있다. 다섯 개의 (부분) 키들은 다른 사람들이 보관하고 있다가, 원래 소유주가 그 중요 파일을 복화화 할 수 없을 때만 사용되도록 할 수 있다.

PGP의 윈도우 버전은 이러한 키 분할 기능을 지원한다.

7.1.4.6 암호를 이용한 안전한 데이타 전송

안전한 데이타 전송이란 안전하지 못한 (것으로 추정되는) 네트웍을 통해 안전하게 데이타를 교환하는 것이다.

요구 사항
등급 이상의 시스템에서는 안전한 데이타 전송이 요구되고 다음 분류로 나뉘어 질 수 있다:

  1. 통신 상대방 인증 : 통신 양쪽(사용자 & 프로세스)은 데이터 교환전 자기들끼리 식별 및 인증해야 한다.
  2. 데이타 무결성 : 데이타는 전송되는 도중 완전하게 보존되어야 한다. 사용자 데이타, 감사 추적 데이타에 대한 인가되지 않은 조작 및 전송 재생 은 확실히 에러로 판별되어야 한다.
  3. 데이타 기밀성 : 인가된 사람만이 데이타에 접근할 수 있어야 한다.(e.g. end-to-end 데이타 암호화).
  4. 데이타 출발점 인증 : 수신하는 프로세스는 데이타가 누구로부터 오는지 알고 있는가? 등급 시스템들에 대해서는, 송신 부인 방지가 필요하다: 데이타 수신시, 데이타의 송신자를 유일하게 식별하고 인증할 수 있어야 한다. 수신자는 정보가 어디에서 오는지에 대한 증거를 (e.g. 전자서명) 가지고 있는가?
  5. 수신 부인 방지 : 송신자는 보내진 정보를 의도된 수신자가 받았는지에 대한 증거를 가지고 있는가?
  6. 접근 통제 : 비인가 복호화에 이용될 수 있는, 이전에 전송된 모든 정보에 대해 인가된 사람만 접근할 수 있어야 한다.

안전한 데이타 전송은 암호 사용으로 얻을 수 있다. 두가지 주된 암호 방법이 있는데, 공개 키와 공용 키 방식이다. 보통 안전한 통신에는 두개를 혼합해서 사용한다.

안전한 전송을 위한 암호 사용
인증 시스템을 선택할 때, 깨려면 상당한 노력이 필요한 서명 기능과 암호화 방법 및 해쉬 기능을 선택한다.
전 절에 설명한 암호화 알고리듬들을 결합해서 안전한 데이타 전송을 위한 시스템을 만들어낼 수 있다. (아래 그림 참조):

  1. 데이타 무결성: 메시지의 데이타 부분에 대해 MD5 축약이 생성된다.
  2. 송신 부인 방지: 공개 키사용. 즉 송신자는 자기의 비밀키로 메시지 전체 또는 부분을 암호화한다. 대개 메시지 축약만이 암호화 된다 (성능 때문에) . 수신자 (송신자의 공개 키로 복호화), 송신자의 비밀키는 송신자만이 알고 있으므로, 메시지가 올바른 송신자로부터 왔다는 것을 확신한다. 성능문제 때문에, 보통 위에 언급된 MD5 축약만 암호화 하면 충분하다. 송신자의 비밀 키로 암호화된 축약을 서명 이라고 한다.
  3. 수신 부인 방지: 여기서는 다루지 않는다.
  4. 데이타 기밀성: 메시지의 기밀 부분이 암호화 된다. 공용 키 암호화가 가장 효율적인 방법이다 (성능면에서). 보통 공용 키는 양쪽 모두가 알고 있는 정보로부터 계산된다. e.g. 송신자는 자신의 비밀 키 + 수신자 공개 키, 그리고 수신자는 자신의 비밀 키 + 송신자 공개 키. 공개 키 알고리듬의 수학적 특성때문에 이들은 모두 동일하고 유일한 키를 생성하게 된다. (즉, 승수로 올라간 숫자를 곱함). 이 데이타 암호화 키는 대개 세션 키 라고 불린다 (특정 세션에 대해서만 유효함).
  5. 통신 상대방 인증: 송신자와 수신자가 상대방을 절대적으로 확신해야 하는 경우, 인증기관이 괜찮은 해결책이다. 양쪽이 공통된 기관을 신뢰한다면, 이 기관은 양측의 보증서를 확인하는 데 이용될 수 있다. E.g. 송신자가 자기의 공개 키, 이름 ( 및 다른 확인 정보) 을 CA에게 보낸다. CA는 이 정보를 할 수 있는데 까지 입증하고, 패킷에 자기의 각인을 덧붙여 수신자에게 보낸다. 수신자는 이제, 송신자 스스로 자기가 누구라고 하는 것 보다는 더 확신할 수 있다. 위 경우와 비슷한 암호화 및 해쉬가 이 데이타에 적용된다.
  6. 접근 통제: 여기서 다루지 않는다 (구현 형태에 따라 다름).

데이타가 전송될 준비가 되었다:

수신 후 데이타는 복호화 된다:

이러한 접근방법을 사용하는 시스템의 예:: Sun의 Secure RPC (hence NIS+, NFS), SKIP, S/MIME도 크게 다르지 않다.

안전한 파일교환을 위한 FTP 사용

Ftp는 여러 플랫폼에서 표준으로 사용 가능하다. 그래서, 예를 들자면 유닉스와 IBM 메인프레임 간 파일을 전송할 때 편리한 방법이라고 생각하게 될 것이다. (Note: 가능하면 SSH/SCP 를 사용하라, 하지만 SSH는 모든 플랫폼에서 사용 가능하진 않다.) FTP 보안 개선을 위해 어떤 일이 필요한가?

  1. Ftp는 사용자이름과 패스워드를 평문으로 보내므로, 패스워드 보호를 주된 보안 방벽으로 삼아서는 안된다.
    • 자동화된 환경에서, 사용자 이름과 패스워드는 미리 정해진 알고리듬에 따라 매일 양쪽 모두에서 바뀔 수 있다.
    • Ftp 서버측은 모든 연결을 로그해야 한다.
    • Ftp 서버측은 잘못된 패스워드가 수신되면 계정을 불능시켜야 한다.
  2. 파일을 전송전에 암호화 하고 수신 후 복호화한다. (송신지 증명이 필요하면 비밀/공개 키를 사용한다).
  3. MD5 축약을 이용해서 파일 무결성을 검증한다.
  4. Ftp 소스를 바꿔서 원치않는 명령어를 제거할 수 있고(e.g. get 만 허용), 디폴트 포트를 바꾸거나 프로토콜을 약간만 변경할 수 있다.- 이 모든 것이 보안을 강화한다. 소스는 다음에서 구할 수 있다: ftp.uu.net:/packages/bsd-sources.
  5. SSH는 또한 안전한 터널을 통해 PSAV FTP를 설정하는 데에도 사용될 수 있다. (SSH2 는 암호화된 ftp 클라이언트를 포함한다: 권고).

7.2 암호화 제품/프로토콜 견본

7.2.1 암호화 제품

보다 광범위한 SSH와 암호 제품들이 수록된 최신의 기사를 SecurityPortal 에 수록한 관계로 이 절은 축소 했다. 이 기사들을 참고하기 바란다:

[1] 국제적으로 사용가능한 강력한 암호 제품들,  sp/int_crypto.html 또는 SecurityPortal 에 실린 버전.
[2] SSH에 관한 모든 것 , sp/ssh-part1.html  또는 SecurityPortal 에 실린 버전.

7.2.2 암호화 프로토콜
SSL

넷스케이프의 secure socket layer 는 클라이언트 & 서버 인증, 무결성 검사, 압축 및 암호화를 제공하는 "플러그 인" socket layer 이다 (443 포트 또는 HTTP with SSL). 현재는 인터넷 초안이다 (아직 승인 안됨), 아래 TLS 절을 참고.
TCP/IP 스택의 전송 계층에 맞게 설계되었고 (Berkeley sockets 처럼), 응용프로그램들 (telnet, ftp, HTTP 같은) 아래에 있다. SSL은 1994년 7월에 발표되었다. 이것은 인터넷 WWW 상용 응용프로그램에서 사용되도록 설계되었고, LAN 에서도 사용할 수 있다. 넷스케이프 Navigator 와 마이크로소프트 explorer 모두 SSL V2 와 V3 를 지원한다. SSL3를 지원하는 웹서버로 아파치와 넷스케이프가 있다.

알고리듬:
클라이언트는 서버에 연결해서 지원되는 암호화 알고리듬 목록을 보낸다. 서버는 알고리듬 이름, 공개 키, 공용 키 및 해쉬 알고리듬 이름으로 응답한다. 클라이언트는 공개 키가 진짜 그 서버의 것인 지를 검사할 수 있다. 클라이언트는 세션 키를 생성해서 서버의 공개 키로 암호화, 서버에게 전송한다. 서버는 이 세션키를 (자신의 비밀 키로) 해독 하고, 이를 사용하여 그 세션동안 전송되는 데이타를 암호화 한다. 클라이언트는 임의의 문자열을 세션키로 암호화하여 서버에게 보내 서버를 검사한다. 서버는 수신을 확인한다.
위의 인증 기법은 서버가 클라이언트를 인증하는 데에도 사용할 수 있으나, 이 때 서버가 클라이언트의 공개키를 가지고 있어야 한다 (WWW 응용프로그램의 경우 해당이 안됨).

  • SSL은 키 교환 기능이 내장되어 있어, 안전하게 특정 서버에 연결하고자 하는 클라이언트를 도와준다. 일반적으로, 서버는 클라이언트를 인증할 수 없는데, 클라이언트의 공개 키를 인증할 방법 없이 받기 때문이다. 이러한 체계는 WWW 상거래 요구사항과 맞는다. 하지만, 서버가 클라이언트의 전자서명(인증서)을 가지고 있다면, 인증할 수 있다.
  • 인증, 압축, 무결성 검사 및 암호화의 핵심 기능은 정확하게 분리되고 독립적으로 사용될 수 있다.
  • SSL V3은 암호에 독립적이며, 암호 및 압축 알고리듬의 선택은 클라이언트가 아니라 서버에 달려있다. 정의된 알고리듬은 MD5 와 SHA (무결성 검사를 위해 - 해쉬), RSA (공개 키 암호화를 위해) 및 RC2,3,4 (서로 다른 변형으로), DES (40 & 56 bit) 그리고 3DES (대칭적 암호화를 위해) 이다.
  • 대부분 사이트는 WWW 클라이언트와 인터넷 사이에 방화벽과 HTTP 프락시를 가지고 있다. 이것은 "중간자"를 피하도록 설계된 SSL에 문제를 일으킨다. SSL 터널링 CONNECT 확장이라는 것이 있다(예를들자면 넷스케이프 프락시 서버에서 이를 지원한다). SOCKS 도 또한 프락시에 사용될 수 있다. SSL은 프락시에의해 캐쉬될 수 없으나 브라우저에서는 될 수 있다 (아마도 암호화 되지 않으므로). [
  • => 높은 보안의 응용프로그램에서 SSL 을 사용하는 데 있어 큰 문제는 미국의 수출규제를 받고, 따라서 암호화 강도가 낮다는 것이다. (미국 기관이 우리를 쉽게 감시하도록). ] (→ 현재는 사정이 조금 달라짐:역주)
  • HTTPS는 SSL 계층의 꼭대기에 있는 HTTP 로, 보통 443 포트를 쓴다. HTTPS를 써보려면 , https://networth.quicken.com 에 접속한다. 넷스케이프 Navigator를 쓴다면, 아래 왼쪽 구석에 있는 깨진 열쇠가 "깨지지 않은" 것으로 바뀌면서 세션이 암호화 된다는 것을 나타낸다. 열쇠의 이 하나가 40 bit를 2개의 이는 128 bit 암호화를 나타낸다.
  • 보안 이메일 (sstmp/ 465 포트 및 spop3/ 995 포트) 및 보안 NNTP (snews, 563 포트) 와 같은 다른 서비스들도 SSL 상에서 돌아가도록 할 예정이다.
  • SSL 키 교환 취약점은 www.baltimore.ie/developers/sslattack.html 에 문서화 되어 있다.

참고:

  1. SSL, V2.0 문서 home.netscape.com/newsref/std/SSL_old.html .
  2. V3.0 문서 home.netscape.com/eng/ssl3/index.html 또는 home.netscape.com/newsref/std/SSL.html .
  3. SSL-Talk Email discussion list: ssl-talk-request@netscape.com 에 *subject* 를 SUBSCRIBE 로 하여 메일을 보낸다.
  4. Secure Sockets Layer Discussion List FAQ, www.consensus.com/security/ssl-talk-faq.html . 
  5. SSL 구현에 대한 논의는, [1] 참고.

TLS (Transport Layer Security)

1995 년, IETF는 SSL을 TLS라는 인터넷 표준으로 채용하는 작업을 시작했다. 1997년 3월에 SSL 3.0을 기반으로 하여 프로토콜 초안이 발표되었다. 몇 가지 차이점은 무결성 검사에 MD5 대신 HMAC을 사용하고 지원되는 암호 알고리듬이 약간 다르다는 것이다. www.consensus.com/ietf-tls  또는 www.ietf.org/html.charters/tls-charter.html 참조.

PCT

마이크로소프트의 Private Communication Technology (PCT) 는 SSL을 대체하기 위해 만들어졌다. 이것은 본질적으로 좀더 일반적이다.인증과 암호화 협상이 분리되어 있다. 이것은 마이크로소프트의 Explorer 3.0 에서 사용되며 다른 어떤 것과도 호환되지 않지만, 표준이 될 지도 모른다.
마이크로소프트는 IETF (1996년 4월) 와 넷스케이프에, 인터넷 상거래를 위한 호환성 있는 솔루션을 보장하기 위해 SSL/PCT 조합의 구현을 제안했다. pct.microsoft.com 참조 (옛날 링크인데 대체사이트가 발견되지 않음)

S-HTTP (Secure HTTP)

S-HTTP 는 HTTP 프로토콜의 연장으로 "일반" TCP/IP 상에서 돌아갈 수 있고, CommerceNet 에서 개발했다. 트랜잭션 기밀성을 위한 서비스를 제공하며, 응용프로그램 계층에서, secure HTTP 연결에서 동작한다. 현재 구현된 것은 CommerceNet CA 이다.

  • S-HTTP 는 넷스케이프 Navigator 와 마이크로소프트 explorer 에서 지원? 또는 Spyglass 클라이언트와 OpenMarket 서버에서만 지원? 7070 포트 사용?
  • RSA 와 DSA가 서명에 사용된다.
  • DES 와 RC2 가 암호화에 사용된다.
  • MD2, MD5 또는 SHA가 메시지 축약에 사용된다.
  • PGP, MOSS 및 PKCS-7 의 캡슐화 형식이 사용될 수 있다.
  • 키 교환은 Diffie-Hellman, Kerberos, RSA, In-band 를 쓸 수 있다. 공개 키는X.509 나 PKCS-6 형식으로 저장된다.
전자 상거래

전자 상거래는 다음을 위한 안전한 방법을 필요로 한다:

  1. 온라인 구매/판매를 위한 안전한 지불 (아래 SET 참조)
    • 클라이언트의 신용카드 상세정보는 상점 서버에 저장될 필요가 없도록 하여 (정상적인 구매가 일어날 때), 오늘날 온라인 거래의 주된 위험을 없앤다.
    • 구매자는 상점의 신원을 확인할 수 있어햐 하고 상점은 고객의 신용 정보를 확인할 수 있다.
    • 양쪽 모두 거래를 부인할 수 없어야 한다.
    • 지불은 자동적으로, 전자적으로 이루어질 수 있다.
  2. 지불 세부내역의 비밀성과 무결성 (e.g. 신용 카드 정보). SSL은 일반적으로 고객과 상점간의 온라인 주문 세션에 대한 비밀성과 무결성을 보호하기 위해 사용된다.

제품 견본:

SET (Secure Electronic Transmission)

Secure Electronic Transmission은 전자 상거래를 위한 프로토콜 세트로 VISA, MasterCard 및 American Express에 의해 제안되었다 (1996년 2월부터). SET은 MIME 을 사용하여 메시지를 전송한다. SET 1.0 은 1997년 5월 공개되었고, TCP/IP 뿐만 아니라 대부분의 매체를 통해 통신할 수 있다.
인증: 서버은 인증을 요구하고, 서버 키는 CA에 의해 인증되며, 클라이언트와 키가 교환되고 거래가 발생한다. SET 전자 인증에는 계정 번호와 공개 키가 포함된다.

SET 2.0: 버전 2.0 은 필요성이 많은 암호화 중립적 아키텍쳐의 특징을 가지게 되어, 더 빠른 (SET 1.0에서 쓰인 RSA 암호화보다) 전자 상거래 응용프로그램의 개발을 촉진할 것이다. Certicom, 애플 컴퓨터, 그리고 RPK 같은 벤더들은 모두 스스로를 RSA에 대한 대안으로 자리매김 하려 하고 있다. 타원형곡선 암호시스템 (Elliptic Curve Cryptosystem, ECC)은 Certicom 과 애플 양쪽에서 밀고 있는 기술이다.

제품:

DNSSEC

표준 DNS가 각 DNS 도메인이 공개 키를 가지고 병렬 공개 키 기반구조를 제공하도록 확장되었다. 도메인 키는 부팅시 올라오거나 부모 도메인으로부터 안전하게 전송된다.
BIND의 새로운 버전도 참조한다. ftp://ftp.isc.org/isc/bind/src/ ,  www.tis.com 그리고 IETF charter www.ietf.org/html.charters/dnssec-charter.html.

암호해독 & 암호화 크래커
AccessData

AccessData 라는 회사에서는 (Utah, phone 1-800-658-5199, www.accessdata.com )  WordPerfect, Lotus, Microsoft Office 및 ACT, Quattro Pro, Paradox,  PKZIP, 등등에서 사용하는 내장된 암호화 체계를 부수는 패키지를 ~ $200 에 판다.
이것은 단순히 패스워드를 추측하는 것이 아니다 ? 실제 암호 해독을 하는 것이다.

7.3 인증

읹으은 어떤 주체의 신원을 확일하는 프로세스이다. 주체는 (주도자,당사자라고도 불리는) 사용자가 될 수도 있고, 시스템 또는 프로세스가 될 수도 있다 즉, "네트웍 실체" 이다. 인증은 양쪽이 모두 알고 있으나 다른이들은 모르는 어떤 것, 즉 주체의 특성이나 가지고 있는 또는 알고있는 어떤 것을 사용한다. 따라서 이것은 생체 측정이 될 수도 있고 (지문, 망막 패턴, 손모양/크기, DNA 패턴, 필적 등), 패스프레이즈(passphrases), 패스워드, 일회용 패스워드 목록, ID 카드, 스마트 토큰, challenge-response 목록 등이 될 수 있다. 어떤 시스템은 이들의 조합으로 구성되기도 한다.

오늘날 강력한 인증기법 중 가장 흔한 것은 일회용 패스워드 목록 (종이), 자동 패스워드 생성기 (스마트 토큰) 및 지능적 ID 카드이다.

7.3.1 인증 메카니즘 요약

현재는 산업 표준이 없다. 여러가지 많은 노력들이 진행중이다. 특히 Federated Services API, GSS API 그리고 RADIUS 는 벤더들이 기존의 제품을 버릴 필요 없이 현재의 비호환 시스템들을 상호연결하는 논리적인 방법인 듯 하다. 하지만 그런 API가 기본적인 기능 이상의 것을 제공한다는 것이 상상이 잘 안되긴 한다.(앞선 기능들이 모든 제품에 공통적인 것은 아니므로). IETF 에도 현재 활동중인 인증 그룹이 여러 개 있다:

전사적 인증과 네임 서비스용으로는 DCE, NIS+ 와 NODS 가 현재의 선두 주자들이며, 마이크로소프트의 Active Directory service (planned for release with NT5 ) 는 이미 NT 도메인 사용 기업의 관심을 끌고 있다. X.500 디렉토리 서비스는 이들 대부분에서 볼 수 있을 것이며, 상호 운용 게이트웨이 구축을 허용하게 된다. DCE 나 NIS+ 가 PC 클라이언트를 완전히 받아들이지 않은 것은 유감이지만, 이는 아마도 가격과 복잡성의 문제를 반영하는 것이다.

SSH 는 유닉스 시스템에의 안전한 접근을 위한 정말 인상적인 제품이다. RSA, SecurID 또는 UNIX 사용자/패스워드 인증을 사용할 수 있다.

안전하지 않은 네트웍을 가로지르는 인증을 위해서는, 인증서나 토큰 기반 인증을 사용하는 고유(비호환, 고비용) 암호화 방화벽이 현재의 해결책이다. 추후 있음직한 SKIP 이나 IPsec 같은 제안표준 수용으로, 바라건대, 장기적인 상호 운용성이 제공될 것이다.

로그온

클라이언트/서버 응용프로그램은 IBM 메인프레임으로부터 VMS, UNIX 에서 PC 까지 여러가지의 많은 시스템들에서 운영된다. 불행히도 이 시스템들은 각각 자기만의 사용자 인증 방식을 가지고 있다. 데이타베이스 로그인은 대개 OS (사용자) 로그인과 통합되지 않는다. 보통은 사용자 이름과 패스워드로 시스템에 대해 사용자를 인증한다. 각 시스템과 응용프로그램이 자신의 로그온 프로세스를 가지고 있다면, 사용자는 (아마도) 서로 다른 사용자 이름과 패스워드 배열에 마주치게 된다. 이것은 진짜 보안 위험을 야기한다. 사용자가 여러가지 패스워드를 모두 적어놓거나, 거의 바꾸지 않거나, 단순한 것을 사용하게 되기가 쉽기 때문이다.

이상적인 해결책은 안전한 single signon 을 제공하는 것이다. 즉 사용자가 네트웍상의 어떤 워크스테이션에 로그온 할 때, 그의 신원이 인식되고 모든 시스템이나 응용프로그램과 공유될 수 있다. 모든 사용자는 아무곳에서나 어떤 시스템에라도 동일한 이름과 패스워드를 가지고 서명할 수 있다. 사용자는 하나의 패스워드만 기억하면 된다. 더욱 안전한 signon은 사원 ID 카드를 이용하여 사용자를 확인하거나 (각 워크스테이션의 카드 판독기로) 들고 다니는 스마트 카드를 이용하는 것이다 (일회용 패스워드와 함께).

Single signon 을 구현하는 것은 현대의 이질적 환경에서는 쉽지 않은 작업이지만, Kerberos 가 주요 주자인 것 같고 SUN의 NIS+도 선택사항인 것 같다.

방화벽 & 인증

강력한 인증은 (보통) 사용자가 알고 있는 어떤 것과 (e.g. 패스워드) 사용자가 가지고 있는 어떤 것에 (e.g. 목록, 스마트 카드) 의존한다. 응용프로그램은 인증 메카니즘을 지원해야 한다 (또는 인증 메카니즘이 응용프로그램에게 투명해야 한다). 다음은 강력한 방화벽 인증 방법/제품 견본이다.

Telnet, Rlogin 또는 ftp (쓰기가능) 같은 프로토콜이 허용되는 경우, 방화벽에서의 강력한 인증 메카니즘은 매우 중요하다. TCP/IP 는 본질적인 보안 취약점을 가지고 있으며 (기밀성, IP spoofing) 이들은 강력한 인증 제품에서 다루어야 한다. 키를 사용하는 경우, 키 분배가 고려되어야 한다. 

표준은 없으며, 각 제품은 자신의 API를 가지고 있고 상호운용은 대개 아주 힘들다. 어떤 방화벽 인증 서버는 접착제 처럼 동작해서, 여러가지 인증제품에 공통 데이타베이스 사용을 허용하고 있다 (예로써 Gauntlet 인증 서버가 있다).

HTTP 기본인증

HTTP 에서는 기본 인증 방식이 지원된다.

알고리듬: WWW 클라이언트가 기본 인증으로 보호되는 문서에 대한 요청을 보낸다. 서버는 접근을 거부하고 기본인증이 필요하다는 헤더 정보와 함꼐 401코드를 보낸다. 클라이언트는 사용자에게 사용자이름과 패스워드를 넣을 다이얼로그를 띄워주고, 이를 서버에게 보낸다. 서버는 사용자이름과 패스워드를 검사하고 맞으면 문서를 보낸다.
암호화: 매우 약하다. 사용자 이름과 패스워드는 base64 방식으로 부호화된다. 문서는 평문으로 보내진다.

NT Domains / Lan Manager / SMB & NetBIOS /NetBeui /CIFS

NT의 도메인은 (IBM/Microsoft) Lan Manager (LM)의 확장이며, 계층적이지 않고 도메인 기반이다 - 즉 분리된 LAN 들에 더 적합하다.
LM 인증은 몇 개의 변형이 있다: PC NETWORK PROGRAM 1.0, MICROSOFT NETWORKS 3.0, DOS LM1.2X002, DOS LANMAN2.1, Windows for Workgroups 3.1a, NT LM 0.12, CIFS. 마지막 두 개가 가장 관심을 끄는 것으로 NT4 에서 사용되었다.

  • 처음 두세개 변형은 지원된다고 하더라도 아주 오래된 것으로 (그리고 SMB 프로토콜을 쓰는 클라이언트가 요청한다) , 패스워드를 평문으로 보낸다.  NT4 와 Win95의 1997년 가을 패치는 디폴트로 암호화 사용을 강제한다. 삼바의 1997년 말 버전도 암호화를 지원하고 더욱 재미있게도 인증을 "통과한다".
  • 몇 가지 취약점이 1997년 초에 공개되었고 NT4.0 SP3과 개뱔 패치에서 부분적으로 고쳐졌다. Win95 도 몇 개의 패치가 있다.
  • 마지막 두개의 변형만 빼고 (즉 NT4) 모든 방언에 대해, 네트웍을 지나간 암호화된 메시지를 크랙하는 것이 그렇게 어렵지 않다: 사전(dictionary) 공격에 LM의 대문자 패스워드와 7 byte 2 단어 분리등을 합치면 크래킹 작업은 매우 쉬워진다.
  • NT4 메카니즘 (NT LM 0.12)은 더 좋지만, 그래도 재생 공격을 당하기 쉽다. NT4 호스트는 오로지 NT LM 0.12 만을 받아들이도록 구성될 수 있지만, 그러면 Win95 클라이언트는 통신할 수 없다.
  • 마이크로소프트는 아마 계층적 도메인을 NT5 에서 선보일 것 같다 (expected 1999).
  • For a technical explanation of the security problems involved with the TCP/IP NetBIOS 파일공유 프로토콜과 관련된 보안 문제의 기술적 설명에 대해서는 (CIFS 라고 불리는- Common Internet File System) 다음을 참조: www.microsoft.com/workshop/networking/cifs/default.asp samba.anu.edu.au/cifs/ ftp://samba.anu.edu.au/pub/samba/ .
인증 제품
Kerberos (+ DCE)

Kerberos는 MIT 에서 Athena 프로젝트가 개발한 키 네트웍 인증 서비스이다. 이것은 분산, 실시간 환경에서 네트웍 자원에 대한 요청을 인증하기 위해 사용된다. DES (즉 공용키) 암호화 및 CRC/MD4/MD5 해쉬 알고리듬이 사용된다. 소스 코드는 무료로 얻을 수 있고 (비상용 버전을 위한), Kerberos는 여러가지 많은 시스템에서 돌아간다.

Kerberos는 인증 기관 역할을 하며 키와 티켓을 관리하는 "보안 서버" 또는 Kerberos 서버 (KDC)를 필요로 한다. 이 서버는 각 주체에 대한 (사용자 또는 호스트) 비밀 키 데이타베이스를 유지하며, 보호되는 네트웍 자원에 접근하고자 하는 주체의 신원을 인증하고, 두 사용자가 안전하게 통신하고자 할 때 세션 키를 생성한다.

Kerberos 인증 시스템은 여러가지 버전이 있다 :V3 (MIT), V4 (상용: Transarc, DEC) 및 V5 (in beta/RFC 1510, DCE, Sesame, NetCheque). BSDI 는 Kerberos 서버를 번들로 제공하는 유일한 OS 이다. Solaris 2 는 Kerberos 클라이언트를 번들로 제공하는데, 무엇보다도 NFS가 인증을 위해 Kerberos를 사용할 수 있게 해준다.

[마이크로소프트는 NT5 에서 Kerberos 를 지원할 계획인데, 기존 버전과 얼마나 호환될 지는 두고 봐야 한다.]
Gradient (www.gradient.com)는 DCE를 기업 보안의 중심이 되게 하기 위한 솔루션을 제공한다. SecurID나 Entrust PKI 인증서와 같은 non-Kerberos 인증 시스템에 대한 PC-DCE 인터페이스이다.NetCrusader 보안 서버는 여러가지 인증 원소들을 DCE 원소에 매핑시키기보다 다양한 응용프로그램을 보안 API와 어댑터를 통해 서로 연결하며 SSL,SAP,People's Tools API, Oracle/Sybase 및 Orbix와도 인터페이스 된다.

Kerberos도 문제가 없는 것은 아니다:

  • 전자서명( 및 송신지 증명)이 지원되지 않는다.
  • 클라이언트와 서버 소프트웨어는 Kerberos를 위해 "kerberized" 되어야 한다.
  • 관리가 복잡하다.
  • 평문 패스워드가 보안 서버에 저장될 수 있다.
  • "윈도우" 가 몇시간이고 인증된 채로 남아 있을 수 있다.
  • 단일 공격지점: 보안서버는 전적으로 신뢰되므로 침범당했을 경우 전체 네트웍이 침범된 것이다. (이것은 부분적으로 공개 키 암호가 사용되지 않았기 때문이다). Kerberos는 확장이 되지 않는다. 즉 계층적 도메인 개념이 없다. 사용자/시스템 조합은 인증되지 않는다.
  • V4, V5, DCE 나 Sesame 변형들 간의 비호환성.
  • 국제 버전은 암호화가 없다.
  • 가용성: 백업이나 복제 서버가 없다?
  • nii-server.isi.edu/info/Kerberos 참조  
NIS+

NIS+ 는 계층구조의 전사적 네임 시스템으로, Secure RPC를 기반으로 한다. 디폴트 구성에서는 사용자,그룹,서비스 네이밍, automounter 및 키 분배를 제공한다. NIS+는 맞춤테이블을 정의할 수 있도록 쉽게 확장될 수 있다.

NIS+는 유닉스의 실제적 표준인 NIS (Network Information System, or yellow pages) 의 개선된 버전이다. NIS 와 NIS+ 는 Sun 에서 개발했다. NIS는 대부분의 유닉스 플랫폼에서 사용가능하지만 보안이 매우 취약하다. NIS+는 훨씬 더 안전하지만 Sun의 Solaris와 최근에는 HP-UX 및 AIX 에서만 사용가능하다.

보안은 Secure RPC의 사용을 기반으로 하는데, SecureRPC는 또 Diffie/Hellman 공개 키 암호 시스템을 사용한다.

  • NIS+ 는 매우 유연성이 있고, 쉽게 확장되어 맞춤 테이블을 관리할 수 있다.
  • 업무 시스템에 사용하기에 충분한 안정성이 있다 (패치가 올바로 설치된 Solaris 2.3 이나 이후 버전에서)
  • 계층적 구조를 가지고 있어, 전사적으로 사용할 수 있다.
  • NIS+ 는 Solaris 2.5 이상부터는 Sun의 Federated Services (아래 참조)에 통합된다.

단점:

  • Sun의 현재 구현 제품은 좀 더 나은 GUI가 필요하다.
  • Windows 나 NT 클라이언트가 1995년 초에는 있었는데, 현재는 Sun의 "Solstice client" 가 NIS+를 지원한다. 마이크로소프트에서는 지원하지 않는다.
  • 관리가 복잡하고 잘 설계된 GUI 관리 도구가 없다.
  • Secure RPC 가 쓰는 키 크기는 512 bytes 인데 현재 웍스테이션의 속도로 보아 증가될 필요가 있다.
  • 패스워드/설정 변경할 수 있는 사용자 GUI가 없다.
  • 패스워드 변경 클라이언트 nispasswd 는 고정된 초기 룰을 가지고 있다. (즉 별로 유연하지 않다) 그리고 사전(dictionary) 검사도, 이전 사용된 패스워드 저장도 허용되지 않는다. or password generation.
BoKS

BoKS는 PC 및 유닉스 시스템을 위한 완전한 인증/single signon 패키지로서, 스웨덴의 DynaSoft 에서 만들었다. DynaSoft는 10년 정도 되고 직원이 50명 정도인 회사이다. 다음은 그 홈페이지에서 추출한 것이다: www.dynas.se/prod/prod_eng.html :

The BoKS 개념은 1987년부터 DynaSoft 가 개발하고 개선해 왔다. 이것은 접근 통제, 강력한 인증, 암호화, 시스템 감시, 알람 및 감사 추적 등과 같은 분야를 다루는 종합적인 보안 솔루션이다. BoKS 는 유닉스 및 도스/윈도우 환경에서 동작하며, 높은 신뢰성을 제공하고 대부분의 유닉스 플랫폼에 올라간다. BoKS 는 또 Tivoli 같은 전사적 관리 시스템 및 Oracle이나 Sybase 같은 데이타베이스 응용프로그램과도 통합될 수 있다.

BoKS는 Secure Dynamics SecurID 스마트 토큰을 사용한다. 저자는 실제로 BoKS에 대한 경험이 많지 않지만, 높은 수준의 보안이 요구되는 곳에서 광범위하게 쓰이고 있는 것으로 보인다. 유닉스 (SunOS, Solaris and HP-UX) 와 PCs (Windows & NT) 에서 운영된다. BoKS 는 공용 키 암호화를 사용한다.

Bellcore S/Key

S/Key는 Bellcore 에서 만든 일회용 패스워드 시스템이다. 공개 버전으로 사용 가능하다. 특징은:

  • 비밀을 저장할 필요가 없다.
  • 도청/재생 공격으로부터 보호한다. 사용자의 비밀 패스워드가 네트웍을 돌아다니지 않는다.
  • 서버는 대부분의 유닉스 시스템과 연동된다. PCs/MAC/UNIX 상에서 패스워드 생성을 할 수 있다.
  • 일회용 패스워드의 목록은 테이블을 토대로 할 수 있다. 각 패스워드는 한번만 사용되고 사용자는 한번 로그인 할 때마다 패스워드를 목록에서 지워 목록의 다음 패스워드가 다음 로그인에 사용되는 식으로 한다. 이러한 솔루션은 특별한 하드웨어가 필요 없으므로 저렴하다. 한가지 위험은 패스워드 목록이 도난당할 수 있다는 것이다.
    참조: ftp://thumper.bellcore.com/pub/nmh/skey skey-users-requests@thumper.bellcore.com
OPIE (One-time Passwords In Everything)

OPIE는 U.S. Naval Research Laboratory 에서 만든 공개 도구이다. OPIE 는 S/Key 버전1의 개선된 버전으로 POSIX 호환 유닉스 류의 시스템에서 운영되며 S/Key에 비해 다음의 추가적인 특징을 가진다:

ACE Server (SecurID)

Secure Dynamics (현재는 RSA Security:역주) 의 SecurID 시스템은 현재 시장에서 보다 인정받는 제품들 중 하나이다. 대부분의 클라이언트와 동작하며 (유닉스, NT, VPN 클라이언트, 터미날 서버 등) 많은 방화벽들에서 SecurID 지원을 제공한다. 사용자 데이타베이스를 관리하고 접근을 허가/거부하는 서버는 ACE 라고 한다. 저자는 이 시스템을 사용해서 다양한 클라이언트 상의 수백명 사용자들에게 안전한 원격 접근을 제공한 적이 있다.

토큰은 SecurID 라는 이름을 가지고 기본적으로 신용카드 크기의 마이크로 컴퓨터로, 일분마다 유일한 패스워드를 생성한다. 이에 덧붙여 각 사용자는 4문자의 핀코드를 가지고 있다 (카드 도난에 대비). 사용자가 로그온 했을 때, 자기 핀(PIN)을 입력하고, 거기에 SecurID 토큰에 나타난 현재 패스-코드를 입력한다. 서버는 동일한 알고리듬과 비밀 암호화 키를 가지고 있어, 양쪽이 모두 안전하게 인증할 수 있도록 한다. Win95/NT용 소프트웨어 토큰도 있고 모토롤라에서 만든 SecurID 모뎀도 있다. 토큰은 보통 3년 정도 간다.

이러한 형태의 인증은 강력하지만, 세션이 하이잭 당할 위험이 있다. (예를 들어 일회용 패스워드가 자주 바뀌지 않을 때).

비용: 스마트 토큰은 대개 $60 (매 3년) 정도 하는데, 사용자가 많이 있으면 비싸게 보일 수 있는 가격이다, 특히 서버 소프트웨어비용이 사용자당 $150 씩 추가될 때.
안정성: 저자는 ACE 서버를 200 명의 사용자. 설치가 좀 불편하긴 하지만, 매우 견고하고 한번도 고장난 적이 없다 (Solaris 2.5 나 2.7에서).

서버는, 고가용성을 위해 미러링을 지원하는데, 유닉스에서 운영되고, 클라이언트들은 거의 모든 플랫폼이 가능하다. ACE는 Motif GUI를 통해 구성되는데 확실히 완전하지는 않다. 좀더 유용한 GUI 는 NT 원격 관리 도구에서 사용할 수 있다. ACE 는 NT/RAS,ARA, XTACACS 및 RADIUS 인증 프로토콜을 지원한다. www.securitydynamics.com/products/datasheets/asvrdata.html 또는   www.securitydynamics.com 을 참조한다. 몇몇 syadmin 들의 노트를 보려면 www.livingston.com/tech/docs/radius/securidconfig.html 를 참조한다.

Safeword

Secure Computing www.securecomputing.com 의 Safeword 는 ACE/SecurID 의 직접적인 경쟁자이다. 서버는 유닉스상에서 운영된다. TACACS, TACACS+ 와 RADIUS 같은 많은 인증 프로토콜을 지원한다.

많은 토큰 종류가 지원된다: Watchword, Cryptocard, DES Gold & Silver, Safeword Multi-sync 및 SofToken, AssureNet Pathways SNK (SecureNet Keys). www.safeword.com/welcome.htm 를 참조한다.

Watchword

Racal Guardata 에서 만든 이 일회용 패스워드 시스템은 SecurIDs 의 경쟁자로, 좋게 인정받고 있다. 기본적으로 다음과 같이 동작한다:

  • 서버는 문장을 하나 생성한다. (클라이언트 상의) 사용자는 이 문장을(challenge 라고 불림) Watchword 계산기에 입력한다. 계산기는 또 다른 문장을 보여주고, 사용자는 이 문장을 집어 넣는다. 서버는 이 문장이 허가된 Watchword 계산기에 의해 생성됐는 지 확인하고, 맞으면 접속을 허용한다.

공격은 선택된 평문 추측의 형태로 발생할 수 있다. Racal Guardata 에서는 Access Gateway도 생산한다.

Defender Security System

AssureNet Pathways 에서 만든 이 시스템은 NT에서 운영되므로(위의 대부분처럼 유닉스가 아니고) NT 서버 사용자들에게 흥미가 있을 것이다. 특징: ARA, NT/RAS, TACACS+ 를 통한 인증. 데이타베이스 복제를 통해 다중 서버가 가능하다.

사용되는 토큰은 SecureNet Keys (SNK) 하드웨어나 소프트웨어 토큰이다. challenge/response 인증은 DES를 사용하고, PIN 은 절대로 네트웍을 통해 전송되지 않으며 민감한 정보는 암호화된다. www.axent.com/product/def2.htm 참조

원격 접근 톤제 프로토콜
RADIUS (Remote Authentication Dial In User Service).

Merit Network 과 Livingston 은 신원확인과 인증을 위한 RADIUS 프로토콜을 개발하였다. IETF 에 RADIUS 표준을 정의하는 작업 그룹이 있다.

  • RADIUS는 벤더 독립적인 프로토콜로, 사용자에게 다중 dial-in 접속점을 제공할 수 있게 해 주고 중앙화된 인증용 사용자 데이타베이스를 가지고 있다. 하지만 표준에 대한 벤더들의 확장분이 있고 표준은 진전되고 있는 중이라, 모든 구현제품이 호환성 있는 것은 아니다.
  • RADIUS는 전송되는 패스워드를 공용 "비밀"을 사용하는 해쉬 기술로 암호화한다. 이 비밀은 대역 외 통신으로 양쪽에 전해져야 한다.
  • ftp.merit.edu/radius/releases 와   ftp.livingston.com/pub/radius 를 참조한다.
  • 표준 RADIUS로는 패스워드를 바꿀 수 없다, www.funk.com/new_one/SBR/faq_steel.htm 를 참조.
XTACACS (Enhanced Terminal Access Controller Access System)

XTACACS 는 다중 프로토콜을 지원하는 BBN으로부터 나온 UDP 기반 시스템인 TACACS (Terminal Access Controller Access System)를 강화한 것이다. SLIP/PPP, ARA, Telnet 및 EXEC 프로토콜을 지원한다.

TACACS+

역시 TACACS 를 강화한 것이지만(CISCO에서), XTACACS 나 TACACS 와 호환되지는 않는다. SLIP/PPP 와 telnet에 덧붙여 S/key, CHPA, PAP 를 통한 인증을 허용한다. 인증과 인가가 분리되어 있으며 개별적으로 구성이나 기능하도록 할 수 있다.

  • UDP 에 반대하여 TCP를 사용한다. (보안 강화).
  • 전송 정보는 암호화될 수 있다.
  • ACL 및 패스워드 기간지정을 지원한다.
  • 강화된 감사 및 빌링 기능.
PPP 인증 프로토콜: PAP, CHAP

PAP (패스워드 인증 프로토콜) 은 사용자 이름과 패스워드를 서버에 평문으로 전송한다. 패스워드 데이타베이스는 약하게 암호화된 형식으로 저장된다. CHAP (Challenge Handshake Authentication Protocol) 은 challenge/response 교환으로 각 로그인마다 새로운 키가 사용된다. 그러나, 패스워드 데이타베이스는 암호화되지 않는다. 몇몇 벤더들은 PAP 와 CHAP 프로토콜을 강화시킨 변형들을 제공하는데, 예를 들면 CHAP에서 패스워드를 암호화된 형식으로 저장하는 것 등이다.

다른 인증 방법들
  • 생체인증은 1998/9 년도에 최전선으로 나오고 있다. 한가지 예는 컴팩의 Win95 & NT 인증용 지문확인기이다. $100 정도 한다. www.compaq.com/im/fit/index.html 을 참조한다 .
  • 다른 계층적 전사 네이밍 시스템들도 있는데, Banyan Streetalk III 와 Novell's Netware Directory service 같은 것들이다.
  • 방화벽이나 dial-in 서버에 쓰이는 강력한 고유 인증 제품들은 여기서 논의하지 않는다.
  • STEL: 인증을 위해 S/Key, SecurID 및 UNIX 패스워드를 지원하고 암호화에는 3DES, DES 및 IDEA를 지원하는 안전한 telnet 이다. ftp://idea.sec.dsi.unimi.it/cert-it/ 참조.
  • FNS (Federated Naming Services ): X/Open FNS 는 여러가지 인증 시스템을 한데 모으기 위한 표준화된 API (XFN)를 제안한다. 응용프로그램들은 이 API 하나에만 인터페이스하면 된다. Federated services API는 그러면 어떤 인증 시스템이 어떻게 호출되어야 하는지를 결정한다. XFN 은 기본적인 네이밍 기능을 위한 단일하고 일정한 인터페이스 하에 다중 네임 서비스를 연합하는 방법을 제공한다. 서비스는 네이밍 인터페이스를 통해 합성 이름 (다중 네임 서비스에 걸치는) 분석을 지원한다.The service supports
    • 이것은 (예를들어) 다양한 Kerberos 방언(변형)들, RSA, NIS+, 그리고 아마 Lan Manager나 Novell 까지도 단일화 하는데 사용 될 수 있다. 이러한 시작이 어떤 일을 불러 일으킬 지 보는 것도 재미있을 것이다.
    • XFN 은 SunSoft, IBM, HP, DEC, Siemens 및 OSF 에서 활발하게 지원된다.
    • FNS 은 Sun의 Solaris 2.5 에서 표준 네임 서비스로 포함되었으며, NIS+, DNS and X.500 같은 전체적인 네임 서비스에 대한 지원 뿐만 아니라 조직,사용자,호스트, 사이트, 서비스 명명에 특정한 정책과 관행을 가진 전사적 규모의 네임 서비스들로 구성된다.
  • RSA 인증 서비스 : RSA 알고리듬은 PGP나 SSH 같은 많은 제품에서 사용하고 있지만, RSA 사 자체적으로도 사용하고 있다.
  • MISSI (Multilevel Information Systems security Initiative) : NSA는 이전에 분류된 인증 기술을 대중에게 제공하려는 노력의 일환으로 MISSI 를 후원한다. MISSI 는 사용자 및 메시지 인증을 제공해야 하고 저렴하며 이식성이 좋아야 한다. MISSI는 현재 여러 벤더에서 개발하고 있다. (LJL, SecureWare, MykotronX, Spryrus).
    • 공개 & 비밀 키 암호가 결합되고, 키 분배 센터와 최소한의 컴퓨터적 부담을 가진다. 부정하게 조작할 수 없게 되어 있는(tamperproof) Fortezza 라는 PCMCIA 카드가 개발되어, 키 생성을 담당한다.
    • PC 운영체제(DOS/Windows)에 대한 의존성 및 카드에 키를 다시 발급하기 위한 복잡한 인증 구조가 결점이다.

7.4 접근 통제 목록 (Access Control Lists : ACLs)

ACL 은 누가 (또는 무엇이) 어떤 객체에 접근할 수 있는지를 ( e.g. 사용,읽기,쓰기,실행,삭제 또는 생성할 수 있는 지) 정의한다. 접근 통제 목록 (ACL) 은 데이타 기밀성과 무결성을 보장하기 위해 사용되는 주된 메카니즘이다. A system with 임의적 접근통제 (discretionary access control) 를 가지는 시스템은 사용자들 간의 차이를 판별할 수 있고 각 객체에 대해 ACL을 관리한다. ACL 이 사용자 (또는 데이타 소유주)에 의해 수정될 수 있는 경우, 임의적 접근 통제 로 간주된다. ACL이 시스템에 의해 지정되어야만 하고 사용자가 변경할 수 없는 경우, 강제적 접근 통제 가 사용되고 있는 것이다. 유닉스에서 OS서비스나 응용프로그램에의 접근에 대한 표준화된 ACL은 없다.

  • AIX (선택적으로), DCE 및 윈도우 NT 는 ACL을 사용하여 대부분의 객체에 대한 접근을 다스린다.
  • Solaris 2.5 이상은 파일시스템(UFS,NFS)에 대해 ACL을 제공한다.
  • 보통의 유닉스도 (일종의)ACL을 사용하지만, 다른 이름으로 수행된다. 예를 들면: 파일 보호(/etc/groups), 파일시스템 공유 보호(/etc/netgroups, /etc/exports), 파일 시스템 탑재 (/etc/fstab), 원격 접근 (.rhosts, /etc/hosts.allow), X 윈도우 (xauth, xhost), NIS 네트웍 (/etc/securenets), 프린터 (/etc/hosts.lpd) 등.

7.5 규칙 및 정책을 구현하기 위한 메카니즘

특정 환경을 안전하게 하기 위해서는, 규칙 및 정책이 구현될 수 있게 하는 메카니즘이 필요하다. 네트웍 전반에 걸쳐 유닉스 시스템에 규칙과 정책을 구현하는 것은 쉬운 일이 아니며 대개는 스크립트 개발도 필요하다. 또다른 가능성은 Tivoli 같은 도구를 사용하는 것인데, 이것은 네트웍으로 연결된 이기종 환경에서 규칙과 정책을 구현하도록 설계된 것이다.

NT 는 사용자 마다 전부는 아니지만 어느정도의 권한을 설정할 수 있도록 해 준다. 이것은 유닉스에서와는 매우 다른 접근방법이다. ("NT" 장 참조). 서버 네트웍에 걸쳐 규칙과 정책을 구현하는 것도 표준화된 유틸리티에 의해 지원되지 않는다.

7.6 가용성 메카니즘

7.6.1 백업 및 복원

주의해야할 것들:

  • 가능하다면 가지고 있는 모든 서버에서 동작하는 혼성의 제품을 사용한다.
  • 온라인 색인으로 빠른 복구가 가능하다. 디스크에 백업을 받으면 빨리 복원할 수 있다.
  • 어떤 제품은 사용자가 관리자의 간섭 없이 자신의 파일을 백업하고 복구할 수 있게 해 준다. 쥬크박스(테잎 stacker 라고도 불리는)를 쓰면 카세트를 바꾸는 신체적 노동도 줄일 수 있고 복원 시간도 빨라진다 (더 많은 카세트들을 사용할 수 있으므로). 어떤 시스템은 자동으로 테이프에 라벨을 표기하기도 한다.
  • 하드웨어 및 소프트웨어 압축은 백업 시간을 줄일 수 있고, 네트웍 부하 및 필요한 카세트의 개수도 줄일 수 있다.
  • 네트웍 백업은 네트웍에 심각한 부하를 주고, 예를들어 100개의 4GB 파일 서버를 네트웍을 통해 매일 밤 백업하려 한다든지 하면, 불가능할 수도 있다. 계획이 중요하다.
7.6.2 환경

전산 환경은 에어 컨디셔닝, 잠겨진 서버실 및 UPS (220V 보호) 등으로 보호될 수 있다. and UPS (220V protection).

7.6.3 중복성/여분 (Redundancy)

Redundancy 는 가용성을 높여주고 하드웨어로 구현될 수도 있고(RAID), 디스크 드라이버 또는 OS (RAID) 또는 응용프로그램/서비스 레벨에서 구현될 수도 있다.(e.g. Replication, transaction monitors, backup domain controllers).

7.6.3.1 응용프로그램/서비스 중복성

사용 가능한 경우에는, 대개 이것이 가장 저렴하고 쉬운 방법이다. 주된 문제는 이런 유형의 중복성을 지원하는 응용프로그램이 거의 없다는 것이다. 이러한 서버들에 연결하는 클라이언트들은 1차 서버가 사용 불가능할 경우 자동적으로 백업이나 복제 서버를 찾는다.

  • 네임 서버들은 (NIS+, DNS, NIS, WINS, Lan Manager...) 대개 이러한 기능을 내장하고 있으며 이를 사용하는 것을 적극 추천한다. RAID / 미러링은 이러한 서버들에는, RAID 비용이 더 싸지 않다면, 필요하지 않다.
  • 파일시스템 서버들은 파일을 다른 시스템이나 다른 로컬 디스크에 정기적으로 복제함으로써 (e.g. 사용자 홈 디렉토리 등) (저렴하게) 가용성을 높일 수 있다. 1차 파일 서버에 중대한 고장이 생기면, 사용자들은 두번째 시스템으로부터 파일을 탑재할 수 있다. 하지만, 마지막 복제/동기화 이후 이루어진 변경사항은 잃게된다.
    => 대표적인 제품: Rdist (UNIX), File replicator (NT).
    => 위의 방법은, 중단시간을 줄이기 위해, RAID를 추가하지 않고도 중요 서버에 있는 사용 가능한 시스템 디스크들에 대해 동기화된 복사본을 유지하는 데 사용될 수도 있다.
7.6.3.2 RAID / 미러링

시스템 가용성을 높이는 고전적인 방법은 컴퓨터의 가장 약한 부분을 복제하는 것이다: 바로 디스크이다. RAID (Redundant Array of Inexpensive Disks) 는 중복성을 높이기 위해 표준 디스크들이 어떻게 사용되는 가를 정의하는 사실상의 표준이다. 최고의 RAID 시스템들은 디스크,디스크 콘트롤러, 전원공급장치 및 통신 채널을 복제한다. 가장 단순한 RAID 시스템은 소프트웨어로만 이루어진 디스크 드라이버로, 분리된 디스크들을 하나의 중복 세트로 함께 묶는다.
RAID에는 5개의 레벨이 있다:

  • RAID 1: 기본적으로 미러링이다.
  • RAID 1+: RAID 1 에 Parity 검사를 추가한 것이다.
  • RAID 5: Striping
  • RAID 5+: Parity 있는 Striping (가장 많이 쓰이는 RAID 레벨).

RAID 시스템에서 주의해야 할 점:

  • scsi 포트에 그냥 붙어 있는 블랙박스가 내장된 디스크 콘트롤러보다 관리하기도 쉽고 수리하기도 더 쉽다.
  • 고가용성 시스템 용으로는 절대 최신형을 사지 않는다. 다른 곳에서 6개월/1년 이상 작동이 입증된 RAID 를 구입한다.
  • 표준 디스크를 사용할 수 있는 RAID 를 사용한다.
  • RAID들은 거대한 데이타베이스에서 기대한대로 동작하는 법이 거의 없다. 구매하기 전에 trail 을 해본다.
  • 가능하다면 모든 서버에 같은 RAID를 사용한다 (heterogeneous).
  • RAID 를 위해 특별한 장치 드라이버 및 커널 패치가 필요하다면 유지보수가 어려워지고 중단시간도 아마 길어질 것이다.
  • 소프트웨어만으로 된 RAID 는, 사용한다면, 설치 및 재설치가 쉽고 사용자 인터페이스가 아주 좋은 것으로 한다.
7.6.3.3 시스템 중복성

응용프로그램에서 자체적으로 중복성을 제공하지 않는다면, 특별한 소프트웨어 (그리고 어쩌면 하드웨어도)를 두 대의 시스템에 설치하여 Hot Standby 기능을 제공한다. 원리는 다음과 같다: 두 시스템 모두 공유 디스크(고가용성, 이중 포트)에 접근할 수 있고 중복된 네트웍 연결을 가진다. 백업 시스템은 주 시스템을 지속적으로 감시하다가 주 시스템이 작동하지 않는 것을 알게 되면, 공유 디스크를 제어하고, 주 시스템과 같은 네트웍 주소를 가지도록 자기 자신을 재구성하고, 마스터에서 돌아가던 응용프로그램들을 시작한다.물론 이것은 특정한 응용프로그램인 경우에만 동작한다. e.g. 주서버가 고장나서 주요 응용프로그램이 구성이나 데이타 파일을 파괴한다면 백업 서버는 그 응용프로그램을 시작할 수 없을 것이다.

이것의 예로는 IBM의 HACMP 제품, 또는 Sun의 HA cluster 가 있다.

7.6.3.4 전체 하드웨어 중복성

전문화된 컴퓨터 시스템들은 한대의 시스템에서 완전한 중복성을 제공한다. 즉 CPU, 메모리, 디스크 등등... 이 모두 중복되어 있다. 단일점에 의한 고장이 없다. 이러한 시스템들은 대개 특별히 맞추어진 운영체제를 필요로 하며, 엄청난 비용이 들고 주류 시스템들과 거의 호환성이 없다. 사업용으로는 드물게 쓰이며, 대부분 군용이나 특별한 금융적 용도로 쓰인다.

예로는 Stratos 계열 시스템들이 있다.

관련글 더보기

티스토리툴바