정보보호개론 14주차

해시 : 메세지를 입력으로 하여 길이가 짧은 값으로 변환 혹은 압축한 것

- 정보의 무결성을 확인하기 위한 목적으로 사용

입력 메세지의 길이 상관없이 고정된 길이의 출력 값을 계산

-> 압축 기능 제공

 

해시 함수 특징

1. 일방향성 : 해시 함수 결과값에서 역으로 어떤 메세진지 계산 불가능

2. 충돌 회피 : 서로 다른 입력 메세지에 대하여 서로 다른 결과값 계산

3. 효율성 : 해시 함수는 계산하는데 시간과 자원이 적게 필요함

 

압축 : 2^2,048bit Message ->해시->2^256bit

 

해시 함수

- 메세지 다이제스트 함수

- 메세지 요약 함수

메세지

- 프리 이미지

해시 결과값

- 메세지 다이제스트

- 지문

- 핑거프린트

무결성

- 완전성

- 보전성

 

해시

1. MD

해시 값 크기 128 비트

MD5는 보안 취약점으로 인해 사용 권장X

2. SHA //많이 사용

SHA-1함수는 MD5보다 조금 느리지만 보안성은 조금 더 안전

SHA-1는 충동 문제가 2005년 발견돼 현재는 SHA-2를 사용을 권장

 

해시의 사용목적 및 한계

목적 : 무결성 확인 : 파일 또는 메세지의 변조가 발생했는지 확인 가능

한계 : 누가 이 파일을 보냈는지에 대하여 인증을 증명할 수 없다.

 

메세지 인증 코드 MAC //hash와 비슷

- 메세지 인증(Message Authentication) : 메세지가 올바른 송신자로부터 왔다는 것을 확인하는 것

- 메세지 인증코드(MAC : Message Authentication Code)

-> 메세지를 추가적인 키(인증을 위하여 사용)를 이용하여 MAC 함수를 통해 계산된 값

해시와 공통점 : 결과값의 길이가 미리 정해져 있다.

해시와 차이점 : 함수 계산에 추가적인 키가 필요

-> MAC이 인증의 역할을 할 수 있게 함. (단, 송수신자가 서로 키를 공유해야함.)

=> 대칭키 암호시스템과 유사

 

HMAC(Hash Message Authentication Code)

- HAMC : 해시 함수를 이용하여 메세지 인증 코드를 구현하는 방법

-> 여러 해시 함수들 중에서 필요에 따라 선택 가능

hash 목적

1. 메세지 압축 기능

2. 메세지 무결성 제공

hash 조건

1. 일방향성

2. 충돌회피

hash는 인증기능을 제공하지 않는다.

메세지 인증=>MAC사용

 

MAC의 Key는 사전에 공유

MAC함수는 대칭키, hash 중 선택

 

hash(key||message) -> 한 번에 많은 데이터 처리 가능

 

메세지 인증 코드

제약 1 : 키 배송 문제

- MAC 사용을 위해, 별도의 다른 안전한 방법으로 키를 공유해야함.

제약 2 : 제 3자에 대한 증명의 불가

- 송신자와 수신자 이외의 다른 제3자에게 메세지의 송신자를 증명할 수 없다.

 

제 3자에 대한 증명 불가 : 수신자 부인 불가

부인 방지의 불가 : 송신자 부인 불가

1. Alice가 M(메세지)를 만듦

2. 다음과 같이 계산(Alice)

- MAC = MAC(KAB)(M) ->(M, MAC)를 넘김

3. 다음과 같이 계산(Bob)

- MAC' = MAC(KAB)(M)

4. 다음과 같이 비교

- MAC = MAC'

같으면 메세지 M이 변경이 안됐다 (무결성), Alice가 쓴 것이다. (인증)

틀리면 M변경, Alice가 아니다.

 

MAC은 KAB를 이용하기에 Alice도 Bob도 만들 수 있다.

즉 A와 B는 누가 만들었는지 알지만 그 것을 제 3자에게 증명할 수 는 없다.

-> 부인불가 기능 제공  없음(A,B 둘다 같은 MAC을 생성 할 수 있기에) => 같은 키를 공유하기에

=> 이 문제(부인방지)에 대해 증명을 위해 전자 서명 사용

 

재전송 공격(Replay Attack)

- 악의적인 공격자가 몰래 보관해둔 기존의 정상적 MAC 값을 이용하여 같은 메세지를 반복해서 보내는 공격

대응 방안 1. 시퀀스 번호

- 메세지에 시퀀스 번호를 포함하여 MAC 값을 계산, 시퀀스 번호는 통신(송신/수신) 시마다 1씩 증가

단점 : 송신자와 수신자가 통신 때마다 마지막 시퀀스 번호를 기록해 둬야 한다.

대응 방안 2. 타임스탬프

- 메세지에 현재 시각을 붙여 넣기

- 현재 시각보다 이전 시각의 메세지인 경우, 정상적인 MAC 값이라도 오류로 판단

단점 :송신자와 수신자가 시간을 일치시켜야 함.

대응 방안 3. 비표

- 일회용으로 랜덤하게 수신자가 생성하는 값인 비표를 메세지 안에 추가하여 이를 확인

1. 송신자 A가 수신자 B에게 비표 요청

2. B가 비표 생성

3. B가 A에게 비표 전달

4. 비표 포함 메세지 HMAC값 계산

5. 메세지 + HMAC값 전달

6. 메세지에서 HMAC값 검증 및 비표 확인

단점 : 통신 프로토콜 자체가 달라져야 하며, 이를 위해 주고받는 데이터 양이 증가

 

전자서명

- 서명은 서류에 대한 인증과 부인방지 역할을 한다.

- 전자서명 : 원본 메세지에 대한 해시 값을 서명자의 개인키로 암호화

- 제공 기능 : 메세지에 대한 인증, 부인방지 및 메세지 무결성 검증

 

공개 : eA, eB

개인소유

A : (dA,p,q)

B : (dB,p,q)

1. A가 메세지 M을 선택

2. A가 다음과 같이 계산 //해시 함수 사용

h=h(M) 

3. A가 다음과 같이 서명 //개인키로 서명

S=E(dA)(h) //S=H^(dA) mod M과 같다.

(M(메세지),S(서명))을 B에게 전달 //전달

4. B가 다음과 같이 계산 //복호화

h'=h(M)

h=D(eA)(S)

h'=(h^dA)^eA mod N = h^(eA*dA)=h

5. B가 비교 //비교

h=h'

맞으면 서명 (1. 무결성, 2. 인증, 3.부인 불가)

틀리면 X

 

A의 개인키로 서명 했기에(S 생성) A가 만들었다고 인증이 가능하다.

 

공개키 기반 구조

필요성 => 전자서명 약점 : 전자서명 할 때, 사용된 공개키가 정말 송신자의 공개키인지 증명 필요

- 공개키 인증서(PKC : Public Key Certificate) : 신뢰할 수 있는 인증 기관(CA, Certification Authority)을 이용하여 신뢰할 수 있는 안전한 공개키 제공

- 공개키 기반 구조(PKI : Public Key Infrastructure) : 공개키를 효과적으로 사용하여 안전한 암호화와 전자서명 기능 등을 제공하는 보안 환경 ex) 인터넷 뱅킹에서 사용되는 공인인증서

 

공개키 인증서(PKC) : 사용자의 공개키에 사용자의 식별 정보를 추가하여 만든 일종의 전자 신분증

사용 시나리오

1. 인증서 등록 및 배포 : Bob이 공개키, 개인키 생성 후 공개키를 인증기관에 등록

-> 인증기관의 개인키를 이용하여 Bob의 공개키가 맞다고 서명

S(B)=dC(eB)

EeC(SB)=eB

eB^(dC*eC)=eB //인증기관의 서명과 공개키를 이용하여 B의 공개키를 A가 알음

2. 인증서 검증 및 공개키 사용

A는 인증서로 알게 된 B의 공개키를 이용하여 암호문 전송

B는 암호문을 자신의 개인키로 복호화

 

공개키 인증서 

- 공개키와 공개키의 소유자가 누구인지 저장된 전자 문서

- 신뢰할 수 있는 인증기관인 CA가 전자서명하여 생성

-> 대부분 공개키 인증서는 X.509라는 표준에 따라 생성