🟧 메시지 무결성이 필요한 이유
간단하게 말하면, 메시지가 중간에 조작되거나 변조되지 않도록 보장해야 한다.
메시지가 변경되었다면 수신자는 잘못된 행동을 할 수도 있기 떄문이다.
네트워크 내 한 쌍의 라우터 간의 경로를 결정하기 위해 링크 상태 라우팅 알고리즘을 사용 네트워크가 있다.
링크 상태 알고리즘에서 각 라우터는 네트워크 내 모든 다른 라우터들에게 링크 상태 메시지를 보내야 한다.
라우터의 링크 상태 메시지는 직접적으로 연결된 이웃들의 목록과 이 이웃들로의 연결 비용을 포함하고 있다.
한 라우터가 모든 다른 라우터로부터 링크 상태 메시지를 받으면 네트워크 전체 지도를 생성해 낼 수 있다.
최소 비용 라우팅 알고리즘을 수행하여 포워딩 테이블을 설정할 수 있다.
알고리즘에 행할 수 있는 비교적 단순한 공격은 잘못된 링크 상태 정보를 담은 가짜 링크 상태 메시지를 배포하는 것이다.
따라서 무결성이 필요하다.
🟧 암호화 해시 함수 (Cryptographic Hash Function)
암호화 해시 함수는 입력 데이터를 고정된 길이의 해시값으로 변환해준다.
해시 함수는 입력 m을 받아서 해시라 불리는 고정된 크기의 문자열 H(m)을 계산한다.
m : 메시지
H(m) : 메시지에 대해 송신자가 만들어낸 해시값
암호화 해시 함수 특징
- 단방향성
- 해시값을 계산하기는 쉽지만 역으로 복원하기는 어렵다.
- 고정된 길이
- 입력 데이터의 길이에 상관없이 항상 고정된 길이의 해시값을 생성한다.
- 일관성
- 동일한 입력은 동일한 출력을 보장한다.
이러한 이유로 침입자가 입력 데이터를 예측하거나 조작하기 어렵기에 동일한 해시값을 갖는 다른 메시지 y
를 위조하기 어렵다.
해시 알고리즘 종류
- MD5 해시 알고리즘
- SHA-1 (Secure Hash Algorithm)
🟧 메시지 인증 코드 (MAC, Message Authentication Code)
메시지 무결성을 어떻게 얻을 수 있는지 알아보자.
인증키 (Authentication Key)
메시지 무결성을 위해서는 암호화 해시 함수 사용 외에도 송신자와 수신자가 공유 비밀키🔑(s)
를 공유할 필요가 있다.
이때 비트열 형태인 공유 비밀키🔑(s)
는 인증키🔑(authentication key)
라고도 부른다.
공유 비밀키🔑 (Shared Secret Key)란?
대칭 암호화에서 사용되는 키.
즉, 대칭키를 의미한다. (예: AES, DES, .. 알고리즘 기반)
아래에서는 간편하게 부르기 위해 "인증키🔑"라고 부르겠다.
"암호화 해시 함수" + "인증키🔑(s)"를 이용한 메시지 무결성 플로우
(그림과 비교하면서 과정을 보는게 좋을 거 같다.)
송신자는 메시지📨(m)
을 생성한 후 인증키🔑(s)
와 접합하여 메시지📨(m) + 인증키🔑(s)
를 만든다.
해시 h = 해시(메시지📨(m) + 인증키🔑(s))
를 계산하고,
이것을 메시지 인증 코드(MAC, Message Authentication Code)
라고 부른다.
송신자는 MAC
을 메시지 메시지📨
에 첨부하여 확장 메시지 = (메시지📨, 해시(메시지📨 + 인증키🔑))
를 생성해서 수신자에게 송신한다.
수신자는 확장 메시지 = (메시지📨, h)
를 받으면 알고 있는 인증키🔑
를 이용하여 MAC 해시(메시지📨 + 인증키🔑)
를 계산한다.
해시(메시지📨 + 인증키🔑) == h
일 때 수신자는 문제없다고 판단한다. (메시지 무결성)
🟧 전자서명 (digital signature)
공개키 암호화 기술은 전자서명의 구현을 위한 기반 기술로 적합하다.
메시지 인증 코드(MAC)로 전자서명을 생성할 수 없다.
해커😈는 메시지를 조작할 수는 없지만 정상적인 사용자인 척 연기할 수 있다.
때문에 송신자가 정상적인 사용자인지 확인해줘야 한다.
우리는 확인하기 위해 "사용자의 고유 정보"가 필요하다.
전자 서명은 고유한 사용자를 인증해줘야 한다.
이전에 MAC에서 사용한 "키🔑"는 "공유 비밀키🔑"였다.
고유한 정보가 없는 "공유 비밀키🔑"이다.
고유한 특정 사용자를 인증하기에는 불안정하다. 이러한 이유로 "고유 비밀키🔑"를 사용한다고 해보자.
이전 MAC 플로우 그림에서 "인증키🔑"를 "고유 비밀키🔑"로 대체해서 생각해보자.
이제 MAC에서 사용한 "고유 비밀키🔑" 송신자뿐만 아니라 수신자도 가지고 있게 된다.
MAC의 특징으로 암호화를 하지 않기도 하며 "고유 비밀키🔑"를 여러 사용자가 갖고 있다는 것은 "고유"한 것과는 거리가 멀다.
이러한 이유로 고유한 사용자를 식별하기 위해서 MAC을 사용하지는 않는다.
전자서명 생성
메시지📨에 서명한다는 의미는
메시지📨에 사용자를 식별할 수 있는 고유 정보를 적는다고 생각해도 좋다.
헤나가 메시지를 전송한다고 해보자.
개인키🔑(고유 비밀키🔑)
를 이용해서 메시지📨
에 서명한다.
이상하게 보일 수 있지만 서명된_메시지
(개인키🔑(메시지📨)
)를 알고 있다고 해서 사용자가 암호화되어 있는 개인키를
알아낼 방법은 없다.
서명된_메시지
를 공개키🔑
를 통해서 원래 메시지📨
를 알 수 있을 때 헤나가 메시지📨
를 보냈음을 알 수 있다.
다만 암호화 기술
을 이용한 전자서명은 계산 부하가 심하다.
때문에 해시 알고리즘
을 이용해서 데이터의 크기를 최대한 줄여서 암호화
해야 한다.
전자서명 메시지 전송
해시 알고리즘을 이용하면 고정 길이의 지문(finger-print)을 계산한다.
이렇게 되면 기존 메시지보다 훨씬 짧은 길이의 해시 결과를 암호화할 수 있다.
메시지에 해시 함수를 적용한다.
해시 결과에 개인키🔑
로 전자서명한다.
이제 확장 메시지 = (메시지📨, 개인키🔑(해시(메시지📨)))
를 송신한다.
서명된 메시지 검증
수신받은 메시지📨
와 개인키🔑(해시(메시지📨))
를 해시 결과
로 변환하여 일치하는지 비교한다.
공개키 암호화를 이용한 해커 😈
사용자의 메시지가 유출되는 일은 없지만 해커가 정상적인 사용자인 마냥 행동할 수는 있다 !!
해커는 😈메세지📨
를 해커의 😈공개키🔑
, 😈개인키🔑
를 이용해서 송신한다.
수신자는 일반 사용자로 인식하고 해커로부터 받은 😈공개키🔑
를 이용해서 성공적으로 해커의 😈메시지📨
를 수신하는 일이 발생한다.
CA (Certification Authority)
CA는 확실한 신원 보장을 통해서 해커😈가 비정상적인 사용자라는 것을 알 수 있다.
해커😈가 잘못된 공개키🔑
를 줌으로써 수신자가 착각하게 만들 수 있다.
이러한 이유로 수신자는 상대방으로부터 받은 공개키🔑
가 헤나의 공개키🔑
인지 확인해야 한다.
그리고 공개키🔑
가 특정 통신 개체의 것임을 보증하는 일은 인증 기관(CA)
이 해준다.
CA는 신원을 확인하기에 믿을 수 있다.
- 공인 인증 기관
- 신뢰할 수 있는 제3자
- 독립적인 신원 확인 과정을 거치고 규정 및 표준을 준수한다.
- 공개키 암호화
CA 서명 인증서
는공개키 암호화 방식
을 사용하여 데이터의 보안과 신뢰성을 확보한다.- 인증서에는
사용자의 공개키🔑
가 포함되어 있다.
- 서명 및 검증 프로세스
- CA는 신원 확인 절차를 통해 인증서를 발급한다.
- 신원, 소유권, 도메인 소유권 등을 확인하는 단계를 포함한다.
- CA는 인증서에 디지털 서명을 할당하여 위조를 방지한다.
- 디지털 서명은 CA의
개인키🔑
로 생성된다. - 서명된 데이터는
개인키🔑
와 대응하는공개키🔑
를 사용하여 확인된다.
이제 상대방은 CA 공개키🔑
를 이용해서 CA 서명 인증서
에 들어있는 헤나_공개키🔑
를 알아낸다.
해커😈는 CA 서명 인증서를 만들려면 신원 조회를 해야하기 때문에 만들기 힘들다.
(* 해커😈 서명 인증서를 만들어서 정상적인 사용자인척 행동할 수 있을지 확실하게는 모른다. 다만 서명 인증서를 만들기 위해서는 해커의 신원이 필요하므로 해커😈의 정보가 역으로 노출되어 안될거 같다는 생각이다.)
📃 참고
'🌐 네트워크' 카테고리의 다른 글
[네트워크] 애플리케이션 계층 - DNS 서버의 동작 원리 (0) | 2023.06.16 |
---|---|
[네트워크] 애플리케이션 계층 - HTTP, Cookie, Web Cache (0) | 2023.06.14 |
[네트워크] 애플리케이션 계층 - 네트워크 애플리케이션의 원리 (0) | 2023.06.13 |
[네트워크] 암호화의 원리 (0) | 2023.05.28 |
[네트워크 - HTTP] PUT과 PATCH의 차이는 뭘까 (2) | 2023.04.27 |