밍경송의 E.B
[사이버보안] 암호기반 인증- Hash, MAC, 전자서명, 공개키 기반 구조 본문
이 글은 2024-1 ㅇ화여대 (인실 도 교수님의) 사이버보안개론 수업자료를 참고하였음을 밝힙니다.
<관련용어정리>
해시 함수 = 메세지 다이제스트 함수(Message Digest Function)
해시 함수의 입력 메시지 = 프리이미지(Preimage)
해시 결괏값 = 메세지 다이제스트, 지문, 핑거프린트
🔐해시(HASH)
: 메세지를 입력으로 하여 길이가 정해진 짧은 값으로 변환 혹은 압축한 것
정보의 무결성(Integrity) 확인이 가장 큰 목적
👁️해시 함수의 특징
- 입력 M의 길이와 상관 없이 '고정된' 길이의 출력 값 계산
- 일방향성(Onewayness) : 결과값에서 역으로 어떤 입력 메세지였는지 알아내는 것이 불가능해야 함.
3. 입력 M이 다르면 해시값도 다름
- M이 1bit만 달라도 전혀 다른 값이 되어야 함. (plaintext가 유사하다고 해서 결과값도 유사하면 안됨)
- 충돌 회피, 충돌 저항성을 가짐 [충돌 : 입력은 다른데 출력이 같은 경우]
4. 효율성(Efficiency)
- 계산하는 데 시간과 자원이 적게 필요 + 계산 상의 고속성 필요
👁️ 해시 함수의 보안 요구사항
1) Preimage resistance
- Weak onewayness(당연한 일방향성)
- y = h(M)일 때, y와 h를 알아도 M을 찾기 어려워야 함.
2) 2nd Preimage resistance
- Strong onewayness
- 메세지 M과 y= h(M)이 주어졌을 때, y =h(M')인 M'(M!=M)을 찾는 것이 불가능해야 함.
- => output이 동일한 또 다른 input 찾기 불가
** 원래 preimage를 아는 상황에서,이것을 digest했더니 y가 나왔다 -> 똑같이 y가 나오는 M'(preimage)을 찾지 X
(과정을 보면 2)와 3)의 차이 확인 가능)
3) Collision freeness
- h(M) = h(M')이 되는 (M, M')쌍을 찾는 것이 불가능해야 함.
- 내부 부정을 방지하기 위함.
** 처음부터(이게 2)와의 차이) 결과가 똑같이 나오는 M(preimage)의 쌍을 찾지 X
👁️ 해시의 종류
MD5 | 128bit 해시값 크기, 사용권장X |
SHA-1 | 160bit 해시값 크기, MD5보다 느리지만 안전. 충돌문제 o |
SHA-2 | 사용 권장. SHA-256, 382, 512 묶어 표현, 사용 권장 |
SHA-3 | 2012 공모에의해 패택 |
🌼해시 사용 목적 : 무결성(메세지의 변조가 발생했는지 확인 가능)
but, 누가 이 파일(메세지)를 보냈는지. 인증에 대한 증명 절차가 없다는 한계점을 가짐
🔐메세지 인증 코드(Message Authentication Code, MAC)
: 메세지가 올바른 송신자로부터 왔다는 것을 확인하기 위해, 메세지에 추가적인 키를 이용하여 MAC 함수를 통해 계산된 값.
Hash와 MAC의 공통점 | 결과값의 길이가 미리 정해져있음(고정) |
Hash와 MAC의 차이점 | 함수 계산에 추가적인 키가 필요함. MAC의 경우, 키가 입력으로 들어감 |
** 키를 이용하려면, 결국 송수신자가 서로 키를 공유해야 하는데, 이때 일반적으로는 서로 같은 키. 그러니까 대칭키를 사용한다고 함.
이전에 공부했던 대칭키 암호화 알고리즘 글 참조!
https://mgyxxmi0219.tistory.com/92
👁️ HMAC(Hash Message Authentication Code)
: 해시함수 + Key를 추가로 이용해 MAC을 구현하는 방법
*키에 대한 처리 : Key와 M의 길이 일치를 위해 해싱해서 길이를 줄이거나, padding을 붙여 길이를 늘림.
👁️MAC의 취약점과 제약점
취약점
: 대칭키 암호화 알고리즘과 마찬가지로, 키 분배의 문제를 가짐.
-> MAC 사용을 위해 별도의 안전한 방법으로 키를 공유해야 함.
*Replay Attack(재전송 공격)
: 악의적인 공격자가 몰래 보관해둔 기존의 정상적인 MAC 값을 이용해 같은 메세지를 계속 반복해서 보내는 공격
-> 정상적인 MAC값이기 때문에 무결성 check 부분에 걸리지 않음.
Replay attack 대응 방안
1 Sequence Number | - 메세지에 시퀀스 번호도 포함시켜 MAC 값 계산 - 통신(송/수신)마다 1씩 증가 - 송/수신자가 통신 때마다 마지막 시퀀스 번호를 기록해야 함[단점] |
2 Timestamp | - 메세지에 현재 시각 붙여넣기 - 현재 시각보다 이전 시각의 메세지인 경우 정상 MAC값이라도 오류로 판단 - 송/수신자가 시간을 sync해야 함[단점] |
3 Nonce(비표) | - 일회성 랜덤 넘버(nonce)를 메세지 안에 추가하여 확인 - 통신 프로토콜 자체가 달라져야 함 + 메세지 양 증가[단점] |
제약점
-> 송/수신자가 같은 키를 공유하기 때문에 발생하는 문제들
1) 제 3자에 대한 증명의 불가
-> A가 보낸 건지 B가 보낸 건지,, 제 3자에게 증명할 수 없음.
2) 부인 방지 불가
-> 자신이 메세지를 보내지 않았다고 주장할 수 없음
+ 만약 악의적인 공격자가 A인 것처럼 위장하여 변조 프로그램을 배포하면?
🌼전자서명을 통해 제 3자에 대한 증명 및 부인 방지 가능
🔐전자서명
: 1) 원본 메세지 혹은 2) 원본 메세지에 대한 해시값을 서명자의 개인키로 암호화 하는 것
목적 : 메세지에 대한 인증, 부인 방지, 메세지 무결성 검증
-> 평문("사랑해")은 암호화하지 않은 상태로 전송(Confidentiality.기밀성 보장 X)
송신자: 평문을 암호화한 해시값(다이제스트)을 A의 개인키로 암호화하여 전자서명 전송
수신자: 평문을 암호화한 해시값(다이제스트)과, 수신된 암호문을 A의 공개키로 복호화하여 비교함.
👁️전자서명의 ex
- RSA 전자서명구조 : 소인수분해의 어려움을 기반으로 함.
- 타원곡선 전자서명구조(ECDSA) : ECC 기반의 전자서명방식, 짧은 처리 시간.
👁️전자서명의 취약점과 제약점
: 전자서명을 할 때 사용된 공개키가 정말로 송신자의 공개키인지 증명이 필요함.
1) 공개키 인증서(PKC, Public Key Certificate)
- 신뢰할 수 있는 인증기관(Certification Autority.CA혹은 TA)를 이용하여 안전한 공개키 제공
- 일종의 전자 신분증으로, 공개키와 공개키의 소유자가 누군지 저장된 전자문서 🪪
- CA에 의해 공개키 기반 구조(PKI)가 관리됨.
- 우리나라의 경우 KISA, 금융결제원, 이니텍 등이 존재
2) 공개키 기반 구조(PKI, Public Key Infrastructure)
- 공개키를 효과적으로 사용하여 안전한 암호화/전자서명 기능을 제공하는 보안 환경 (ex 공인인증서)
- 구성 : 사용자, 등록기관, 인증 기관, 저장소 등
👁️인증서 사용방법
1) 인증서 등록 및 배포
-> 밥이 자체적으로 공개키를 생성하는 것이 아니라, CA에서 생성 및 배포해줌.
-> 인증기관은 이 키가 밥의 공개 키라는 것을 인증.보장하는 역할을 함.
인증기관의 서명 : CA의 개인 키로 해시값을 붙여 암호화한 것
-> 그렇다면 이 서명은 누가 보장하는가? = 상위인증기관이 보장함.
2) 인증서 검증(상위 인증기관 이용) 및 공개 키 사용
-> 상위 인증 기관의 서명을 통해 인증 기관의 인증서가 검증됨. 보통 2-3계층의 형태로 구성됨.
-> 가장 상위에 존재하는 인증 기관의 경우 ROOT CA(모두가 신뢰하기로 합의한 최상위 인증기관)가 존재함.
'CSE > 사이버보안개론' 카테고리의 다른 글
[사이버보안] 접근제어 (모델) (0) | 2024.06.09 |
---|---|
[사이버보안] 블록체인 (1) | 2024.06.09 |
[사이버보안] 암호개념, 대칭암호화 (0) | 2024.04.25 |
[사이버보안] WEB (0) | 2024.04.25 |
[사이버보안] 네트워크보안 - Sniffing, Spoofing, Session hijacking (0) | 2024.04.24 |