29일차 - 암호화 통신 기초, Hash, 인증서

=======

Hash(128bit)
- Hash값은 파일의 내용에 따라 갈린다.
- 원문 Data는 대칭키로 암호화 , 대칭키는 비대칭의 공개키로 보호
- Data에 대한 Hash값을 송신자의 사설키로 보호해서 보낸다.
- 단 방향 암호화
- Hash는 무결성 검증을 위한 용도 , 복호화 할 필요가 없다.

Hash 특징
- 단방향 암호화 알고리즘
- 다양한 input size와 상관없이 고정된 output size를 가짐
  ex. MD5는 input size와 상관없이 무조건 128bit
- One way(단방향) : 복호화 필요 X, 거꾸로 돌아갈 필요 없는 것 Ex. 믹서기
- Collision Free : 원문이 동일하면 그에 따른 각각의 Hash값은 동일
                      반대로 각각의 hash값이 일치하면 원문이 동일하다는 특징 Ex. 지문
- 주로 메세지 인증에 사용 --> 송수신되는 정보에 대한 위/변조 확인 가능
- 참조 사이트 : winmd5.com

- 알고리즘 종류
  - MD5, SHA . . .


신뢰할수있는 Hash값과 비교했을때 같다면 신뢰할수있다

=======

Diffle-Hellman 방식
- Whitfield Diffle와 Martin Hellman이 발표한 대칭키(비밀,세션) 교환 방법
- 최초의 공개키 알고리즘

1. 수학적 공식을 기반으로 양쪽 시스템에서 임의 값(p,g) 교환
  - p ( 소수 1024bit 이상 )
  - g ( DH 알고리즘 초기 값 , 1 < g < p )
    ex. p : 34 , g : 19

2. 송신자 A 
  - 임의의 개인키(b)생성
     b = 5 ( 오직 송신자 A만 알고 있는 킷값 )
  - 개인키(b)와 p , g 값을 이용해 공개키(a)를 생성
    - a = g^b mod p 로 생성
    - a = 19^5 mod 34 ( 계산기 공학용으로 계산하면 a는 15가 됨 )
  - 수신자 B에게 A에서 생성된 공개키(a) 전달 ( 실제값은 15 전달)
    15(A공개키 값) B에게 전달 --> 오픈되어도 상관없다.

mod=모듈연산

3. 수신자 B
  - B는 임의의 개인키(y) 생성
    y : 3으로 정함
  - 개인키(y)와 p, g 값을 이용해 B의 공개키(x) 설정
    x = g^y mod p 로 구함
    x = 19^3 mod 34, 즉 수신장 B의 공개키 (x)값은 25가 됨
  - 송신자 A에게 공개키(x) 전달
    수신자 B는 자신의 공개키(x) 값인 25를 A에게 전달
  - A의 공개키(a)와 B의 개인키(y)를 이용해 최종 비밀키(s) 생성
    s = a^y mod p, 15^3 mod 34 --> 최종 값 9가 나옴
  ==> B가 사용할 대칭키 값 9가 나옴

4. 송신자 A
  - B의 공개키(x)와 A의 개인키 (b)를 이용해 최종 비밀키(s) 새엉
    s = x^b mod p ,  25^5 mod -> 34 -> 최종 값 9가 나옴
    ==> A가 사용할 대칭키 값 9가 나옴

결론
- 제3자는 p, g, x, a 값을 알아도 A/B의 개인키 값들을 모르기 때문에 최종적으로는 대칭키 값 9를 알아낼 수 있음 

=======

전자서명 ( Message Digest )
  - 원문에 대한 Hash값 생성 후 Hash 값을 송신자 사설키로 암호화한 값
  사귀자 --> 사귀자'('는 hash) 를 송신자(A) 사설키로 암호화한 값이 전자서명 값이 됨
  수신측은 A의 공개키를 이용해 전자서명 값을 검증
  --> A의 공개키로 복호화될 경우 A의 사설키가 사용되었음이 증명 됨
   (사귀자' 신뢰 O)
  --> A의 공개키로 복호화된 Hash값은 신뢰할 수 있게 되며
   사귀자라는 메시지에 대해 Hash값을 생성하면 사귀자' ( 아직까진 신뢰X ) 가 나옴
   결론 : 전자서명 값에서 복호화한 신뢰할 수 있는 사귀자' 와 
   신뢰할 수 없는 사귀자' 를 비교한 후 일치하게 되면
  사귀자라는 원문이 변조되지 않았다는 것이 증명 됨
  - 사용자 인증 / 부인 방지

전자서명은 검증을 위해 보내준다.

=======

인증서 ( Certification )
- 인증서
  - 공개키를 신뢰할 수 있는 제3자(인증기관)의 서명으로 확인하는 증명서
    ex. 부동산 거래 시 공인중계사
        서명으로 확인하는 증명서 예시로 대학졸업장 or 진단확인서
  - 일반적으로 인증서는 표준 x.509 형식을 따름
   → 여러 내용이 들어가지만 2가지만 기억할 것(A의 인증서에 들어가는 내용 중)
         1. A의 공개키 값이 들어감
         2. CA의 전자서명 값이 들어감(가장 마지막 부분에 첨부됨)
      → CA의 전자서명 값은 A인증서에 대한 Hash값을 CA의 사설키로 암호화한 값을 의미
  - 인증서 확인
    * Chrome
      우측 상단 ... → 설정 → 개인정보 및 보안 → 보안 → 인증서관리 → 
      신뢰할 수 있는 루트인증기관 확인 가능
    * edge
      우측 상단 ... → 설정 → 개인정보, 검색 및 서비스 → 보안 → 인증서관리 → 
      신뢰할 수 있는 루트인증기관 확인 가능 
    * 크롬/에지에 저장되어 있는 신뢰할 수 있는 루트인증 기관 정보는 다운로드 받는
      내용이 아님 → 신뢰할 수 있으며, 해당 내용 중 아이콘 모양을 보면 인증서임을
      알 수 있음(인증서에는 공개키가 들어있음을 상기할 것)
      결론 : 신뢰할 수 있는 CA들의 공개키를 OS설치와 동시에 확보하고 있는 상태
 
  - test.com / Client간 암호화 통신하기 위한 CA 필요성
    == test.com ↔ CA(Ex. Verisign) ==
    1. test.com은 공개키/사설키 생성
    2. CA에게 인증서 요청(ex. Verisign), 이때 본인 시스템에서 작성된 공개키값 전송
    3. CA에서 test.com에 대한 인증서 생성
       test.com 인증서에는
       → test.com의 공개키 값 등 X.509형식에 맞게 인증서 작성
       → test.com에 대한 인증서에 대한 Hash 값(test.com’)을 CA의 사설키를 활용해
          전자서명 값 생성 후 test.com 인증서에 첨부
    4. CA에서 test.com에게 test.com 인증서 배포
    5. test.com은 배포받은 인증서 설치 후 서비스할 준비 완료

    == test.com ↔ Client ==
    6. Client에서 인증서 요청
    7. 준비되어있던 test.com 인증서 전송
    8. Client가 test.com의 인증서 검증 진행
       ① 첨부되어 전달된 전자서명 값을 CA(ex. VeriSign)의 공개키로 복호화
       ② 복호화가 잘 되면 test.com’ → 신뢰 O
       ③ test.com의 인증서에 대한 Hash값 생성 → 아직까지는 신뢰 X
       ④ 인증서에 대한 Hash값과 신뢰할 수 있는 Hash값을 비교
       ⑤ 일치한다면 인증서에 대해 신뢰할 수 있게 됨
       ⑥ 최종적으로 인증서를 신뢰할 수 있다는 이야기는 인증서에 들어있는
          test.com의 공개키를 신뢰할 수 있게 됨 
    9. ID/PW를 Client에서 생성한 대칭키로 암호화하고, 
       대칭키는 test.com의 공개키로 암호화하여 전달

11. PKI(Public Key Infrastructure)
  - 공개키 기반 구조
    * 인증서 발급 / 관리 / 배포 / 사용 / 저장 / 취소 등을 안전하고 편리하게 
      효율적으로 수행하기 위한 구조
    * 공개키 관리체계를 의미하며 일종의 암호화 통신을 하기 위한 기반 환경이라 
      생각하면 됨
    * 일반적으로 Trusted Third Party(신뢰할 수 있는 제3자) 디자인으로 구성
      → 신뢰할 수 있는 인증기관을 통해 인증 함
  - PKI 구성요소
    * 인증기관(CA, Certificate Authority)
      → 인증서를 발급하는 지정된 신뢰기관
    * 등록기관(RA, Registration Authority)
      → 인증기관의 역할 중 공개키 등록과 User의 신분 확인을 대행하는 기관
         ex. 은행 
    * 인증서(Certification)
      → User의 공개키가 CA의 전자서명으로 확인된 증명서
    * User
      → 공개키 소유주로 인증서를 요구하는 기관 또는 사용자

데이터들 끼리 체인으로 연결되있다.

=======