일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- IOC
- JSON
- Spring Data Redis
- OOP
- Transaction
- AOP
- jvm
- reflection
- redis
- bytecode
- junit5
- PSA
- MSA
- spring
- SOA
- 서명
- Exception
- bounded context
- ddd
- mockito
- Rest
- *
- JWT
- rest api
- di
- Java
- Generic
- Today
- Total
개발자일기
암호화 방식과 HTTPS 본문
암호화 방식
대칭키 암호화
하나의 키로 암호화 복호화를 모두 하는 암호화 방식
AES(Advanced Encryption Standard), DES (Data Encryption Standard) 방식등이 있다.
공개키(비공개키) 암호화
공개키 암호화라고 불린다. 두개의 키로 암호화 복호화를 하는 암호화 방식이다.
보통 하나의 키는 Private Key(비공개키) 라고 부르고, 다른 하나는 Public Key(공개키)라 한다.
보통 공개키로 암호화 하고 비공개키로 복호화하는 방식이다.
RSA(Rivest, Shamir and Adleman) 방식등이있다.
대칭키 VS 공개키
대칭키는 암화화 키의 공유에 대한 보안적인 문제가 있고, 비대칭키는 속도가 느리다는 단점이 있다.
그래서 https(ssl)에서는 비대칭키의 속도 문제로 인해, 대칭키 암호화 방식도 같이 사용한다.
SSL 인증과 통신
디지털 서명
공개키와 개인키를 이용해 송수신자간의 데이터의 무결성, 위조 되지 않음을 증명하기 위해 사용되는것이다.(말이 어렵다...)
서명 : 전달한 메세지(데이터)에 대한 해시를 개인키로 암호화값
서명은 암호 체크섬이다.
- 서명은 메세지를 작성한 저자가 누군지 알려준다. 작성한 사람만이 개인키를 가지고있어, 체크섬을 계산할수있고, 체크섬은 저자의 개인 서명처럼 동작한다. (체크섬이란?? 네트워크등을 통해 전달된 데이터의 무결성을 검사한다. )
서명은 메세지 위조를 방지한다.
- 도중에 누가 수정한다면, 체크섬을 가지고 있기 때문에 그 메세지의 체크섬과 동일하지 않게된다.
- 디지털 서명은 개인키로 암호화하여 생성된다. 복호화는 공개키로 한다.
예시 )
노드 A -> 노드 B로 메세지 전달
노드 A가 메세지를 hash + 개인키로 서명 생성
노드 A는 서명 + 메세지를 전달
노트 B가 공개키로 서명 복후화후 hash값 복원 , 메세지 hash값 생성후
두값을 비교 => 같은면 위조가 안된것, 다른면 위조
디지털 인증서
신뢰할수있는 기간(CA)에서 받은 인증서이다. 디지털 서명 방식을 이용해서 인증(신뢰성)을 검증한다.
인증서 내용
- 인증서 발급자
- 대상
- 유효기간: 인증서의 유효기간
- 서버측 공개키 : 서버와 통신할때 사용
- 서명을 위한 알고리즘 : 서명을 위해 사용된 알고르즘, "RSA암호화를 이용한 MD5요약"
- 그외.
- 인증기관 서명 : 위의 데이터들에대한 서명 (위의 정보를 "서명을 위한 알고리즘" + 발급 기관의 개인키로 암호화)
http에 SSL인증방식
SSL 디지털 인증서
클라이언트와 서버간의 통신을 공인된 제3자(CA) 업체가 보증해주는 전자화된 문서
(CA: 인증서 발급 기관)
SSL 인증서를 이용한 서버 인증 방식 (서버의 신뢰성 보증)
1 . 인증기관 신뢰성확인.
- 웹브라우져 서버 접속후 인증서 제공받아 서명기관을 확인해본다. 브라우져가 신뢰할수있는 인증기관인지 확인한다.
2. 인증서의 서명확인
- 인증서의 디지털 서명을 검사해본다. (디지털 서명을 CA의 공개키로 복호화, 인증서의 데이터를 해시 적용후 두값이 같은지 비교)
- 동일할 경우 이 서버는 검증된 서버라고 판단한다.
SSL의 동작방식
1. 핸드 쉐이킹
인증서를 통한 서버의신뢰 + 대칭키로 이용할 세션키 생성
- 클라이언트는 지원가능한 암호화 방식(공개키+대칭키+해시 방식)을 전달하고, 인증서를 요구
- 서버는 암호화방식을 선택하고. 인증서와 전달
- 클라이언트는 ssl디지털 서명으로 서버 인증을 확인하고, 인증서에 있는 서버의 공개키를 이용해 대칭키(세션키)로 사용될 값을 암호화해서 서버에 전달
- 서버는 세션키를 개인키로 복호화해서 사용
2. 세션
해당 대칭키값으로 암호화해서 데이터를 서로 주고받는다.
3. 세션 종료
ssl통신이 끝나면 서로에게 종료를 알리고, 대칭키인 세션키를 폐기
공인인증서
은행과 같은 곳에서 (브라우져) 사용자를 신뢰할수있도록 하는것.
사용자가 서버 입장에서 인증(신뢰)를 받는것이다.
공인인증서 발급 요청을 하면 결국엔 사용자의 개인키, 공개키 생성 + 인증서 발급이다.
은행에서 전달해주는 공인인증서라는것은 결국 '개인키 + 인증서' 쌍
그러면 입력하는 비밀번호는 무엇인가??
- 개인이 소유하는 개인키에 아무런 보호 장치가 어려우니 비밀번호를 통해 보호하는것이다. 비밀번호가 필요한 개인키 인것이다.
주요 구성 요소 : ssl 인증서와 거의 동일
- 일련번호
- 발급기관
- 유효기관
- 공개키 : 공인인증서 소유자의 공개키
- 발행기관의 서명값 : 발행기관의 서명(위의 정보들을 Hash + 발급기간 개인키로 암호화)
'개발' 카테고리의 다른 글
동기/비동기 블로킹/논블로킹 차이 (0) | 2020.04.15 |
---|---|
JWT(JSON WEB TOKEN) 개념 (0) | 2020.04.12 |
Redis 트랜잭션, Spring Data Redis (0) | 2020.03.31 |
Effective JAVA Exception처리 (0) | 2020.03.30 |
진정한 Rest Api란 무엇인가? (0) | 2020.03.28 |