ch3_hash 해시

로드맵
Cryptographic hash function
Message Authentication Code
One Time Password

Cryptographic hash function

해시 함수는 아래 성질들을 만족시켜야한다!

• message digest function
  메시지를 일정 비트로 축약한다.

• one-way function
  원본 메세지 m 은 해시함수로 암호화 될 수 있지만, m->H(m)
  암호화된 내용은 원본 메세지로 유추할 수 없어야한다. H(m)-/>m

어떻게 만드는데?
메시지를 패딩해서 512비트의 배수로 만든다.
digest함수를 돌려서 최종 512비트의 결과로 만든다.

해시함수는 integrity와 연관이 깊다.
받은 m과 H(m)을 암호해봐서 값이 같은지 검사할 수 있다.

해시함수는 적어도 256,512비트가 되어야 안전하다.

Message authentication code (MAC)

메세지의 진위여부를 판단할 수 있는 코드

해시함수로 암호화를 하여도 중간에 메시지가 위조되면 이 암호화가 의미가 없어질 수 있다.

해결법
사전에 대칭키를 공유해둔다.
대칭키를 메시지와 합쳐서 해시, 전송
공격자는 대칭키가 없어서 변조할 수 없다.

쿠키랑 세션보낼때도 MAC을 보내서 진위여부를 확인한다 간단하지만 중요하다.

공급망보안 supply chain
가져온 소스코드가 변조된거면 큰일납니다~ 검증해야합니다~

One time Password

인증 과정에서 사용되는 일회용 비밀번호

구현하는 세가지 방법

• Time-synchronized
  은행거래할 때 작은 기기를 줘서 OTP를 발급받는다.
  

시간이 만료되는 시간을 작게하면 네트워크 문제나 기기 문제 때문에 시간이 조금만 지체되면 인증 실패할 수 있다.
그렇다고 시간을 길게 하면 replay attack 당할 수 있다.

NTP: network time protocol

• Challenge-response

은행은 고객이 우리 고객이 맞는지를 시간정보를 쓰지않고 알고 싶다.

1. 은행이 고객한테 랜덤넘버R를 준다.
2. 고객이 h(R||S#||k) 를 만들어서 준다.
3. 은행은 R, 시리얼넘버 S#, 키k를 모두 알기에 해시함수와 비교한다.

• Hash chain

k 값을 고객만 알아야지 은행이 알면 어떡하니??

키를 고객만 알고 은행은 모르게 해보자
1. $h_n(k)$(해시함수를 $n$번 한 것) 만 은행에 알려줌
2. 다음에 결제할때 $h_{n-1}(k)$만 전달해줘서 $h_n(k)$ 을 계산할 수 있게 해서 저장되있는 값과 비교 시킴
3. 이게 맞으면 $h_n(k)$ 지우고 $h_{n-1}(k)$ 만 저장함
4. 이런식으로 $n$이 점점 내려가고 결국엔 은행이 $k$ 를 알게됨 -> 다시 $k$ 와 $h_n(k)$를 갱신해야함