XADM: Secure Sockets Layer 작동 방법

기술 자료 번역 기술 자료 번역
기술 자료: 245152 - 이 문서가 적용되는 제품 보기.
모두 확대 | 모두 축소

이 페이지에서

요약

이 문서에서는 SSL(Secure Sockets Layer) 작동 방법을 개략적으로 설명합니다.

추가 정보

키 암호화 소개

RSA(Rivest-Shamir-Adleman) 공개 키 암호화는 컴퓨터 업계에서 인증 및 암호화에 널리 사용됩니다. Netscape는 자사 제품, 특히 인증에 사용하기 위해 RSA Data Security Inc.로부터 RSA 공개 키 암호화에 대한 라이선스를 취득했습니다.

공개 키 암호화는 암호화와 해독에 비대칭 키 쌍을 사용하는 기술입니다. 각 키 쌍은 공개 키와 개인 키로 구성되어 있습니다. 공개 키는 널리 배포될 때 공개되는 반면 개인 키는 배포되지 않고 항상 기밀로 유지됩니다.

공개 키를 사용하여 암호화한 데이터는 개인 키를 사용해서만 해독할 수 있고 개인 키를 사용하여 암호화한 데이터는 공개 키를 사용해서만 해독할 수 있습니다. 이러한 비대칭은 공개 키 암호화를 매우 유용하게 만드는 속성입니다.

인증에 공개 키 암호화 사용

인증은 한 엔터티가 다른 엔터티의 ID를 신뢰할 수 있도록 ID를 확인하는 프로세스입니다. 다음 예제에서는 사용자 A와 사용자 B가 공개 키 암호화를 사용하여 사용자 B의 ID를 확인합니다. 다음 표기법은 키 암호화를 사용하여 항목이 암호화되었거나 해독되었음을 나타냅니다.
{something}key
여기서 something은 암호화되었거나 해독된 항목에 대한 설명이고 key는 이 항목을 암호화하거나 해독하는 데 사용되는 키입니다.

다음 예제에서는 사용자 A가 사용자 B를 인증하려고 합니다. 사용자 B는 하나의 공개 키와 하나의 개인 키로 구성된 키 쌍을 가지고 있습니다. 사용자 B는 공개 키를 사용자 A에게 공개합니다(공개 키 공개에 대해서는 이 문서의 "공개 키 할당" 절에서 설명함). 사용자 A는 다음과 같이 임의의 메시지를 작성하여 사용자 B에게 보냅니다.
A->B random_message
사용자 B는 다음과 같이 개인 키를 사용하여 임의의 메시지를 암호화하고 암호화된 버전을 사용자 A에게 반환합니다.
B->A {random_message}User_B's_private_key
사용자 A는 이 메시지를 받고 사용자 B가 이전에 게시한 공개 키를 사용하여 이 메시지를 해독합니다. 사용자 A는 해독한 메시지를 자신이 사용자 B에게 처음 보냈던 메시지와 비교합니다. 악의의 사용자는 사용자 B의 개인 키를 알지 못해 사용자 A에게 보낼 임의의 메시지를 올바로 암호화할 수 없습니다. 따라서 두 메시지가 일치하면 사용자 A는 나중에 받은 메시지가 사용자 B가 보낸 메시지임을 알 수 있습니다.

추가 고려 사항

암호화할 내용을 정확히 알고 있지 않는 경우에는 개인 키를 사용하여 이를 암호화한 다음 다른 사람에게 보내지 않는 것이 좋습니다. 왜냐하면 개인 키를 가지고 있는 사용자만 암호화를 수행할 수 있으므로 암호화된 값에 대해 책임을 져야 할 수 있기 때문입니다.

따라서 이 예제에서는 사용자 A가 보낸 원래 메시지를 암호화하는 대신 사용자 B가 메시지 다이제스트를 작성하고 이 메시지 다이제스트를 암호화합니다. 메시지 다이제스트는 원래의 임의 메시지를 기반으로 작성되며 다음과 같은 유용한 속성을 가지고 있습니다.
  • 역엔지니어링하기가 어렵습니다. 따라서 사용자 B로 가장하려는 사람이 메시지 다이제스트에서 원래 메시지를 확인할 수 없습니다.
  • 악의의 사용자가 동일한 다이제스트 값으로 계산되는 다른 메시지를 찾기 어렵습니다.
사용자 B가 다이제스트를 통해 보호됩니다. 사용자 B는 사용자 A가 보낸 임의 메시지의 다이제스트를 계산한 다음 그 결과를 암호화합니다. 사용자 B는 암호화된 다이제스트를 사용자 A에게 다시 보냅니다. 사용자 A는 동일한 다이제스트를 계산한 다음 사용자 B의 메시지를 해독하고 값을 비교하여 사용자 B를 인증합니다.

인증 데이터 가져오기

이 문서의 "추가 고려 사항" 절에서 설명하는 기술을 디지털 서명이라고 합니다. 이 기술을 사용하려면 사용자 A가 작성한 메시지에 사용자 B가 서명해야 합니다. 이것은 사용자 A로부터 가져온 임의의 값을 사용자 B가 암호화하는 것만큼 위험합니다. 따라서 이 예제 인증 프로토콜에는 안전을 위한 하나 이상의 단계가 필요합니다. 사용자 B는 다음과 같이 데이터의 일부(또는 모두)를 가져와야 합니다.
A->B B->A hello, are you User B? User A, This Is User B { digest[User A, This Is User B] } User_B's_private_key
사용자 B는 이 프로토콜을 사용할 때 사용자 A에게 전송되고 있는 메시지를 알고 있으므로 안전하게 메시지에 서명할 수 있습니다. 사용자 B는 먼저 암호화되지 않은 버전의 메시지인 "User A, This Is User B"를 보낸 다음 암호화된 다이제스트 버전을 보냅니다. 사용자 A는 사용자 B가 사용자 B임을 쉽게 확인할 수 있고 사용자 B는 자신이 작성하지 않은 메시지에 서명하지 않아도 됩니다.

공개 키 할당

이 절에서는 공개 키를 안전하게 할당하는 방법을 설명합니다. 다음은 사용자 B에 대한 예제 인증 프로토콜입니다.
A->B B->A A->B B->A
hello Hi, I'm User B, User_B's_public_key prove it User A, This Is
User B { digest[User A, This Is User B] } User_B's_private_key
이 프로토콜을 사용할 경우 누구나 사용자 B로 가장할 수 있습니다. 악의의 사용자에게 필요한 것은 공개 키와 개인 키뿐입니다. 악의의 사용자는 사용자 B의 공개 키 대신 자신의 공개 키를 제공하여 사용자 A를 속이고 사용자 B로 가장할 수 있습니다. 그런 다음 자신의 개인 키를 사용하여 특정 메시지를 암호화함으로써 자신이 사용자 B임을 "증명"합니다. 따라서 사용자 A는 악의의 사용자가 사용자 B가 아니라는 것을 알아채지 못하게 됩니다.

이 문제를 해결하기 위해 표준 협회에서 인증서라고 하는 개체를 개발했습니다. 인증서에는 다음과 같은 정보가 들어 있습니다.
  • 인증서 발급자의 이름
  • 인증서 발급 대상(주체라고도 함)
  • 주체의 공개 키
  • 몇 가지 타임 스탬프
인증서는 인증서 발급자의 개인 키를 사용하여 서명됩니다. 인증서 발급자의 공개 키는 누구나 알고 있습니다. 즉, 인증서 발급자도 인증서를 가지고 있습니다. 인증서는 공개 키를 이름에 바인딩하는 표준 방법입니다.

인증서 기술을 사용하면 누구나 사용자 B의 인증서를 검사하여 위조 여부를 확인할 수 있습니다. 사용자 B가 개인 키에 대한 강력한 제어를 유지하고 있고 실제로 인증서를 받은 경우 인증서 기술은 안전합니다. 다음은 이 기술을 사용하는 수정된 프로토콜입니다.
A->B B->A A->B B->A hello Hi, I'm User B, User_B's_certificate prove
it User A, This Is User B { digest[User A, This Is User B] } User_B's_private_key
사용자 A는 사용자 B의 첫 번째 메시지를 받을 때 인증서를 검사하고 위의 예제에서 설명한 대로 다이제스트 및 공개 키 해독을 사용하여 서명을 확인한 다음 주체(즉, 사용자 B의 이름)를 확인하고 메시지를 보낸 사용자가 실제로 사용자 B인지 확인할 수 있습니다. 그런 다음 공개 키가 사용자 B의 공개 키임을 신뢰하고 사용자 B의 ID 증명을 요청할 수 있습니다.

사용자 B는 메시지 다이제스트를 디자인한 다음 서명된 버전의 다이제스트로 사용자 A에 응답하여 위의 예제에서 설명한 것과 동일한 프로세스를 진행합니다. 사용자 A는 인증서의 공개 키를 사용하고 그 결과를 확인하여 사용자 B의 메시지 다이제스트를 확인할 수 있습니다.

보안 통신을 방해하고자 하는 사용자(이 예제의 경우, 사용자 C)는 다음과 같은 시나리오를 만들어 보안 통신 방해를 시도할 수 있습니다.
A->C C->A A->C C->A hello Hi, I'm User B, User_B's_certificate prove
it ????
그러나 사용자 C는 마지막 메시지에서 사용자 A를 속일 수 없습니다. 사용자 C는 사용자 B의 개인 키를 가지고 있지 않기 때문에 사용자 B가 보낸 것으로 믿도록 사용자 A를 속일 수 있는 메시지를 작성할 수 없습니다.

secret 교환

사용자 A는 사용자 B를 인증한 후 다음과 같이 사용자 B만 해독할 수 있는 메시지를 사용자 B에게 보낼 수 있습니다.
A->B {secret}User_B's_public_key
여기서 secret를 확인하는 유일한 방법은 사용자 B의 개인 키를 사용하여 위의 메시지를 해독하는 것입니다. secret 교환은 공개 키 암호화를 사용하는 또 다른 강력한 방법입니다. 사용자 A와 사용자 B 사이의 통신이 관찰되는 경우에도 사용자 B를 제외한 누구도 secret 정보를 확인할 수 없습니다.

이 기술은 secret를 또 다른 키로 사용하여 인터넷 보안을 강화하지만 이 경우에는 DES(데이터 암호화 표준), RC4 또는 IDEA 같은 대칭 암호화 알고리즘의 키로 사용합니다. 사용자 A는 직접 secret를 만들어 사용자 B에게 보냈으므로 secret를 알고 있고 사용자 B는 개인 키를 가지고 있고 사용자 A의 메시지를 해독할 수 있으므로 secret를 알고 있습니다. 사용자 A와 사용자 B는 둘 다 secret를 알고 있으므로 대칭 암호화 알고리즘을 시작한 다음 대칭 암호화 알고리즘을 사용하여 암호화된 메시지를 보낼 수 있습니다. 다음은 이 기술을 사용하는 수정된 프로토콜입니다.
A->B B->A A->B B->A A->B B->A hello Hi, I'm User B, User_B's_certificate
prove it User A, This Is User B { digest[User A, This Is User B] } User_B's_private_key
ok User B, here is a secret {secret} User_B's_public_key {some_message}secret_key
secret_key를 계산하는 데 사용되는 방법은 프로토콜에 따라 다르지만 secret_key 키는 단순히 secret의 복사본일 수 있습니다.

보안 방해

위의 기술을 모두 사용하는 경우에도 보안 통신을 방해하고자 하는 사용자(사용자 C)는 보안 통신 방해를 시도할 수 있습니다. 사용자 C는 사용자 A와 사용자 B가 교환한 secret를 알아낼 수 없는 경우에도 secret 정보를 다시 정렬하거나 임의로 변경하여 이 두 사용자의 대화를 방해할 수 있습니다. 예를 들어, 사용자 C가 사용자 A와 사용자 B 사이에 앉아 있는 경우 사용자 C는 대부분의 정보를 변경하지 않고 앞뒤로 전달할 수 있지만 다음과 같이 특정 메시지를 임의로 변경할 수도 있습니다. 사용자 C는 사용자 A와 사용자 B가 사용하는 통신 프로토콜을 알고 있으므로 이것은 사용자 C에게 어렵지 않습니다.
A->C C->B B->C C->A A->C C->B B->C C->A A->C C->B B->C C->A
hello hello Hi, I'm User B, User_B's_certificate Hi, I'm User B,
User_B's_certificate prove it prove it User A, This Is User B { digest[User A,
This Is User B] } User_B's_private_key User A, This Is User B { digest[User A, This Is
User B] } User_B's_private_key ok User B, here is a secret {secret} User_B's_public_key
ok User B, here is a secret {secret} User_B's_public_key {some_message}secret_key
Garble[ {some_message}secret_key ]
사용자 C는 사용자 A와 사용자 B가 secret를 공유할 때까지 데이터를 수정하지 않은 채 전달합니다. 사용자 A와 사용자 B가 secret를 공유하기 시작하면 사용자 C는 사용자 B가 사용자 A에게 보내는 메시지를 임의로 변경합니다. 이 때 사용자 A는 사용자 B를 신뢰하므로 사용자 C가 임의로 변경한 이 메시지를 신뢰하고 여기에 응답하려고 할 수 있습니다. 사용자 C는 secret를 알고 있지 않으며 비밀 키를 사용하여 암호화한 데이터를 손상시키기만 할 뿐입니다. 사용자 C는 유효한 메시지를 작성할 수 없지만 프로토콜에 따라 운 좋게 유효한 메시지를 작성할 수도 있습니다.

이러한 손상을 방지하기 위해 사용자 A와 사용자 B는 프로토콜에 메시지 인증 코드를 도입할 수 있습니다. 메시지 인증 코드는 secret와 전송된 일부 데이터를 사용하여 계산되는 데이터 조각입니다. 위에서 설명한 다이제스트 알고리즘에는 다음과 같이 사용자 C에 대해 정의할 수 있는 메시지 인증 코드 함수를 작성하기 위한 올바른 속성만 포함되어 있습니다.
message_authentication_code := digest[ some_message, secret ]
사용자 C는 secret를 알고 있지 않으므로 올바른 다이제스트 값을 계산할 수 없습니다. 사용자 C가 메시지를 임의로 변경하는 경우에도 다이제스트 데이터가 많이 있으면 이러한 변경 작업이 성공할 가능성은 낮습니다. 예를 들어, 사용자 A와 사용자 B는 MD5(RSA에서 개발한 안전한 암호화 다이제스트 알고리즘)를 사용하여 메시지와 함께 128비트 메시지 인증 코드 값을 보낼 수 있습니다. 사용자 C가 올바른 메시지 인증 코드를 추측할 확률은 약 1/18,446,744,073,709,551,616입니다. 사실상 사용자 C는 올바른 메시지 인증 코드를 추측할 수 없습니다.

다음은 이 기술을 사용하도록 다시 수정된 예제 프로토콜입니다.
A->B B->A A->B B->A hello Hi, I'm User B, User_B's_certificate prove
it User A, This Is User B { digest[User A, This Is User B] } User_B's_private_key ok
User B, here is a secret {secret} User_B's_public_key {some_message,message_authentication_code}secret_key
사용자 C는 메시지를 임의로 변경하려고 시도할 수 있지만 메시지 인증 코드를 계산하면 메시지가 사용자 B로부터 전송된 것이 아님을 알 수 있습니다. 사용자 A나 사용자 B는 잘못된 메시지 인증 코드 값을 알아채고 통신을 중지할 수 있습니다. 따라서 사용자 C는 더 이상 사용자 B로 가장할 수 없습니다.



Microsoft 제품 관련 기술 전문가들과 온라인으로 정보를 교환하시려면 Microsoft 뉴스 그룹에 참여하시기 바랍니다.

속성

기술 자료: 245152 - 마지막 검토: 2006년 5월 15일 월요일 - 수정: 3.2
본 문서의 정보는 다음의 제품에 적용됩니다.
  • Microsoft Exchange Server 4.0 Standard Edition
  • Microsoft Exchange Server 5.0 Standard Edition
  • Microsoft Exchange Server 5.5 Standard Edition
키워드:?
kbinfo KB245152
더 이상 지원되지 않는 제품의 KB 내용에 대한 고지 사항
이 문서에서는 Microsoft에서 더 이상 지원하지 않는 제품에 대해 설명합니다. 따라서 이 문서는 "있는 그대로" 제공되며 업데이트되지 않습니다.

피드백 보내기

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com