SSL Record Protocol 구조

SSL Record Protocol 구조 
SSL Handhake Protocol | SSL Change Cipher Spec | SSL Alert Protocol | HTTP | TELNET | —
SSL Record Protocol 
TCP 
IP

SSL Record Protocol : 상호 송수신을 위한 암호화 Cipher sutie가 SSL Handshake 프로토콜에 의해 정해진 후 이러한 Cipher suit 에 따라 실제로 전송하는 데이터를 TCP 패킷으로 변환하하기 위한 기능을 수행
SSL Record Protocol 은 실제 데이터를 전성하기 전에 데이터를 일정한 단위의 조각으로 분리, 압축, 해제 및 메시지 인증 암호화 복호화 기능을 수행

Change Cipher space : 수신측에 어떠한 Cipher sutie에 정의된 알고리즘 키, 압축방식 등을 알려주는 용도로 사용

SSL Alert Protocol : SSL의 동작 과정에서 발생할 수 있는 문제에 대해 경고를 전달하기 위해 사용

Cipher cutie
Server 와 Client 는 어떤 Cipher suite를 사용할 지를 정하게 되는 것.

Cipher suite 의 각 항목들이 의미하는 내용

SSL/ TLS_(A)_(B)_with_(C)_(D)_(E)
(A) : 키 교환 암호 알고리즘
(B) : 인증 알고리즘
(C) : 대칭 암호 알고리즘
(D) : 블록 암호 운용 방식
(E) : 해시 알고리즘

키 교환 알고리즘 : Server 와 Client 간 Key를 교환할 방식을 선정하는 것
인증 알고리즘 : Server와 Client 간 교환한 인증서를 확인하는 알고리즘
대칭 암호 알고리즘 : 실제 데이터를 암호화 하는 알고리즘
블록 암호 운용 방식 : 데이터를 암호화 할 때 한꺼번에 암호화하는 것이 아니라 블록 단위로 암호화 하게 되는데, 블록된 암호화 패킷을 조합하여 데이터를 추측 하는 것을 방지하기 위한 방식
해시 알고리즘 : 서로 상대방이 암호화 한것이 맞는지 확인하기 위한 알고리즘

https://run-it.tistory.com/30




Record Protocol (레코드 필드)

HH VIV2 LIL2 DATA
각 필드들은 아래와 같다. 
- HH: 1 바이트로 레코드 안에 있는 데이터 타입을 결정한다. 아래와 같은 4개의 타입이 정의되어 있다. 
    - 20 : change_cipher_spec
    - 21 : alert
    - 22 : handshake
    - 23 : application data
- V1V2 : 2바이트로 구성되며 현재 사용되는 SSL / TLS 버전을 뜻한다. 아래와 같이 대입된다고 보면 된다. 
    - 300 : SSL 버전 3.0
    - 301 : SSL 버전 3.1 (SSL/ TLS 1.0)
    - 302 : SSL 버전 3.2 (SSL / TLS 1.1)
    - 303 : SSL 버전 3.3 (SSL / TLS 1.2)
- L1 L2 : 전송되는 데이터의 길이를 뜻 한다. 빅 엔디언 표기법이기 때문에 실제 사람이 읽을 수 있는 길이는 256*L2+L1으로 계산해야 한다. 그렇기 때문에 최대 전송 가능한 길이는 18,432 바이트 이지만 실제 이 길이에 도달할 정도로 레코드가 구성되지는 않는다.


Handshake 
- Handshake 는 레코드 단위에서 동작되는 행도, SSL /TLS 의 레코드에 적용할 알고리즘과 키를 교환하는 것에 목적이 있다. 이 Handshake를 마치고 나면 오직 둘만이 소통할 수 있는 세션(session)이라는 통로가 생성된다. 

Handshake는 메시지들로 구성되어 있는데, 각각의 메시지들은 4개의 바이트 헤더를 가지고 있으며 메시지는 레코드 형태로 전송이 된다. 
레코드 형식으로 전송되므로 레코드에서 사용하는 헤더도 역시 포함되어 전송이 된다. 

클라이언트가 지원하는 최대 SSL/TLS 버전 
Client Random : 총 32 바이트로 구성되며 이 중 28 바이트는 Cyptographicially Strong Number Generator 로 무작위로 생성된다. 
Session ID : Abbreviated Handshake 를 사용시 이용됨. SSL / TLS를 다시 사용하고자 할 경우 사용되는 값.

Cipher Suties : 클라이언트가 수용할 수 있는 암호화 기법 목록
Compression Algorithms : 클라이언틀가 알고 있는 압축 기법 목록
Optional Extensions


Cipher cutie 는 16비트로사용할 암호화 기법을 정의. 
E.g) TLS_RSA_WITH_AES_128_CBC_SHA는 0x002F로 표현
의미 :  HMAC/SHA-1과 128 비트 키로 AES 암호화를 사용하며, 키 교환은 RSA로 수행
ClientHello 의 응답으로 서버는 ServerHello를 보낸다. 
- 클라이언트와 서버가 사용할 SSL/TLS 버전
- Server Random : 총 32 바이트로 구성되며 28 바이트는 Client Random 과 동일함
- Session ID : 현 연결에서 사용할 Session ID
- Cipher Suite : 현 연결에서 사용할 Cipher Suite
- Compression Algorithm : 현 연결에서 사용할 Compression Algorithm
- Optional Extensions


전체적인 Handshake 는 아래와 같은 형식으로 진행된다. 
Client  			Sever
Client Hello —> 
				ServerHello
				Certificate*
				SeverKeyExchange*
				CertificateRequest*
		<— 		ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished —>
				[ChangeCipherSpec]
          			<—	Finished

Application Data   <—> Application Data

ClientHello 와 ServerHello 를 마치면 사용하는 cipher cutie 와 다른 인자 값들에 따라 몇몇의 메시지들을 서버는 추가로 보내게 된다. 

- Certificate : 공개키를 담고 있는 서버의 인증서를 보낸다. 클라이언트가 인증서를 보내지 말라고 요청할 때만 보내지 않으며, 그 외는 모두 보낸다. 
- ServerKeyExchange : 키 교환시 인증서만으로 충분하지 않은 경우 사용되는 메시지. 
- CertificateRequest : 클라이언트의 인증서를 요청하는 메시지. 서버가 추가 인증을 필요한 경우 요청하는 메시지, 이 메시지에는 서버가 믿고 있는 상위 인증서 목록을 포함하고 있다. 
- ServerHelloDone : Maker message 로 ServerHello가 끝났다는 것을 알린다. 지금 부터는 클라이언트갖 응답을 시작해야 함을 알린다. 
- 
- 위 메시지를 받으면 클라이언트는 아래와 같이 응답을 해줘야 한다. 
- Certificate : 서버가 인증서를 요청하였다면 클라이언트 인증서를 이 메시지를 통하여 전송한다. 
- ClientKeyExchange : 키 교환시 사용할 메시지
- CertificateVerify : 이전의 Handshake 메시지들을 가지고 계산된 디지털 서명으로서 서버가 클라이언트의 인증서를 요청하였을 경우 응답하게 되는 메시지. 이것을 통하여 클라이언트의 인증서가 진짜임을 알린다.
https://eastdg.wordpress.com/2014/04/09/ssltls-%EA%B8%B0%EB%B3%B8/

ChangeCipherSpec는 handshake 메시지가 아니다. 레코드 타입(타입 20번) 중 하나로서 발송되며 cipher sutie를 서버와 다시 협의하게 된다. 

Finished 메시지는 이전의 서버와 클라이언트간 모든 Handshake 메시들을 가지고 암호학적인 체크섬을 계산한 것이다. 서버는 이 값을 받으면 재 계산을 통하여 자신이 계속 똑같은 클라이언트와 교신을 햇는지 검증하게 된다. 
클라이언트가 ChangeCipherSepc을 요청했다면 서버는 그에 대한 응답을 해주고, Finished 응답을 해준다. 

이것으로 상호간 SSL / TLS을 이용하여 교환하고자 하는 데이터를 전송하게 된다. Session ID를 기억하고 있다면 위와 같은 Full Handshake를 이용하지 않아도 된다. 

Abbreviated Handshake 는 Latency 를 줄이기 위해 자주 사용된다. 일반적인 웹 브라우저는 SSL 연결을 Full handshake를 통하여 열고 나머지는모두 Abbreviated Handshake를 통하여 교신을 한다. 그리고 일반적인 웹서버들은 약 15초간 아무일을 하지 않으면 연결을 끊지만 session ID를 기억하고 있기 때문에 언제든지 Abbrervaited Handshake를 통하여 SSL 연결을 다시 열 수 잇다. 


https://eastdg.wordpress.com/2014/04/09/ssltls-%EA%B8%B0%EB%B3%B8/

Record Protocol 
데이터를 암호화하고 압추갛여 안전하게 전송하는 프로토콜이다. SSL의 실제 데이터를 다루며, Data를 단편화하거나 압축하거나 MAC을 적용하고 암호화하여 이를 TCP에 전달하는 역할을 한다. 

Handshake Protocol
SSL 세션 연결을 수립하는 역할을 한다. 클라이언트와 서버 간의 안전한 연결 수립을 위해서 클라이언트와 서버 간의 상호 인증을 수행하고 암호 메커니즘등의 정보를 교환한다.

Change Cipher Spec Protocol
한 바이트짜리 메시지로서 약속한 암호화 알고리즘 및 키를 적용하여 전송한다.

Alert Protocol
2바이트로 구성되며, 첫번째 바이트에는 warning (1), fatal(2) 이 표현되고 두번째 바이트에는 세부적인 에러코드를 표현. 즉, Handshake, Change Cipher Spec, Record Protocol 수행 중 발생하는 오류메시지를 표현

Application Protocol
SSL 레코드 프로토콜은 다양한 상위계층에 보안 서비스를 제공한다. 따라서 위 그림에서는 SSL 위에서 작동하는 프로토콜로서 HTTP 가 나와있지만, HTTP이외의 다른 프로토콜들(ftp)에도 적용 가능하다.

SSL Record Protocol
SSL 레코드 프로토콜은 상호 송수신을 위한 암호화 스펙이 SSL 핸드 쉐이크 프로토콜에 의해 공유된 후 이러한 스펙에 따라 실제로 전송하는 데이터를 TCP패킷으로 변환하기 위한 기능을 수행.

 SSL 레코드 프로토콜은 이를 위해 먼저 전송하는 메시지를 일정한 단위의 조각으로 분리하는 Fragmentation, 레코드 압축과 해제, 메시지 인증 및 암호화, 복호화 기능을 수행한다. 

동작 방식

SSL 레코드 프로토콜은 각 메시지에 대해 다음과 같은 절차를 통해서 전송을 수행.
먼저 전송할 메시지를 일정한 크기의 레코드 프로토콜 유닛(Record Protocol Unit)으로 분해하고, 각 유닛을 SSL 핸드쉐이크 프로토콜로 사전에 협의한 규칡에 맞게 압축한다. 

어플리케이션 데이터

레크드 프로토콜 데이터
압축된 데이터
메시지 인증코드(MAC)
암호화 된 데이터 
TCP 패킷

Record Protocol 메시지 포맷
Protocol : Version : Length : Protocol message | MAC(option)

필드 : 길이 (바이트) : 설명
Protocol : 1 : Record Layer 프로토콜이 감싸고 있는 프로토콜이 무엇인지 표시, 즉, Record Layer 프로토콜 안의 내용이 어떤 프로토콜의 것인지를 표시
Version : 2 : SSL 의 버전을 표시한다. 주로 3.0이 사용
Length 2 : Record Layer 프로토콜이 감싸고 있는 프로토콜의 내용의 길이를 표시 합니다. 이 길이는 2^14의 값, 즉 16384바이트를 넘을 순 없습니다. 
ProtocoL Message : 16384 바이트 이내의 길이 : Record Layer 프로토콜이 감싸고 있는 프로토콜의 내용
MAC (Option) : 메시지 압축 알고리즘에 따라 달라짐 : Protocol Message 내용의 Mac 값이다. 메시지 인증 기능을 사용할 경우 사용된다. 따라서 이 필드의 사용은 옵션

Protocol 필드 값에 따른 상위 프로토콜은
필드 값 | 프로토콜
20 : ChangeCipherSepc Protocol
21 : Alert Protocol
22 : Hanshake Protocol
23 : 어플리케이션 프로토콜

http://blog.daum.net/tlos6733/56

먼저 HTTP, HTTPS란?
인터넷에서 하이퍼텍스트 (Hypertext)문서를 교환하기 위해서 사용되는 통신 규약. 하이퍼 텍스트는 문서. 중간중간에 특정 키워드를 두고 문자나 그림을 상호 유기적으로 결합하여 연결시킴으로서, 서로 다른 문서라 할지라도 하나의 문서인 것 처럼 보이면서 참조 하기 쉽도록 하는 방식을 의미

Server에 저장되어 있는 데이터를 사용자가 요청하면 그때마다 데이터를 보여주기 위해 사용되는 Protocol이 HTTPS

HTTPS(HyperText Transfer Protocol over Secure Socket Layer)는 월드 와이드 웹 통신 프로토콜인 HTTP의 보안이 강화된 버전

HTTP는 인터넷 상에서 평문통신이라하여 외부의 어떠한 공격자가 있다면 패킷을 탈취하여 어떠한 데이터들이 왔다갔다하는지 볼 수 가 있다. 하지만 HTTPS를 이용한다면 서버와 사용자간의 통신을 암호화 하여 왔다갔다하는 데이터를 서버와 사용자 이외에 아무도 볼 수 없게 한다. 


HTTPS 통신의 기초
TCP 통신을 위해서 3-way handshaking 과정을 거치게 된다. 암호화 통신, SSL 통신을 위해서 SSL-handshaking 과정을 거치게 된다. 

이 과정은 암호화 통신을 하기 위해 어떠한 암호화 방식을 이용할 것인지를 정하는 과정

1. 최초의 TCP 통신을 위해 3-way hanshaking 통신 진행
2. 이후 SSL 통신을 위해 Client 에서 Client Hello 패킷을 전송
    1. Client Hello 패킷이란?
        1. Client HTTPS 통신을 하기 위한 환경을 알려주는 것
        2. SSL Version은 무엇이 사용가능한지, Cipher Suite는 어떠한 알고리즘이 사용 가능한지 Server 에게. 전달하는 패킷
    2. Client Hello 패킷을 전달 받은 Server는 Server Hello 패킷을 전달
        1. Sever Hellow 퍠킷이란?
            1. Client 로 부터 전달 받은 Client Hello 패킷을 확인 후 Client 가 제공한 환경 중에 선탥하여 어더한 SSL Version, Cipher Sutiee 알고리즘을 이용하여 암호화 할 것인지 선택
    3. 최종 SSL 현상이 끝나면 Server 가 가지고 있는 인증서과 키를 교환한 뒤, 암호화된 Application Data를 전송

HTTPS 통신 실제 사례[WireShark]

HTTPS 통신을 하기 위한 전체 통신 과정을 나타낸다.

TCP 3-way-hanshaking 과정이 끝난 뒤 Client Hello 패킷을 전달하는 과정. 내용은 Client 에서 사용할 수 있는 Cipher suite 알고리즘 리스트를 전달하는 것을 확인

Client Hello 패킷을 전달 받은 Server는 Server Hello 패킷을 전달하는 그림
내용에 보시면 Cipher sutie는 어떠한 알고리즘을 사용할 것인지 정해서 Client 에게 알려주는 내용이 포함

협상과정이 끝나면 인증서와 키를 교환하여 암호화 통신을 시작한다.

1. https://run-it.tistory.com/27?category=673442


SSL / TLS 프로토 콜은 Recored 프로토콜 과 상위 레이어 프로토콜로 구성

상위 레이어의 프로토콜은 Handshake, Change Cipher Spec, Alert Application Data 4개의 서브 프로토콜로 구분

- Record 프로토콜은 TCP 프로토콜 위에서 동작하며, 상위 계층 메세지를 분할, 압축하고, 메시지 인증 코드 (MAC) 추가 및 암호화하는 작업을 수행
- Handshake 프로토콜에서 클라이언트와 서버는 상대방을 확인하고 사용할 키 교환 방식, 암호화 방식, 키 생성에 필요한 값 등을 전달하여 암호화 채널 수립을위한 항목들을 협상
- Change Cipher Spec 프로토콜은 Handshake 과정에서 데이터 암호화 용 대칭키 생성이 완료되고 나면 이후부터 데이터를 암호화하라는 신호를 보낸다. 
- Alert 프로토콜은 통신 과정에 오류 발생시 경고 메시지를 전송
- Application data 는 HTTP 와 같은 상위 계층 응용프로그램의 데이터가 실제로 암호화되어 전송되는 부분

SSL / TLS 취약점 및 공격 유형
- SSL/TLS는 중간자 공격 (Man-in-the-middle attack) 에 취약하여, Handshake 단계에서 암호화 알고리즘 및 SSL/TLS 버전 등을 협상하는 과정에 공격자가 개입하여 협상 내용을 보안에 추약한 것으로 변경하는 방식(다운그레이드)의 공격이 많이 발생.
- 다운그레이드 공격 외에도 각 버전에서 지원하는 암호화 방식이나 암호화 알고리즘의 취약성을 이용한 공격도 자주 발생한다. 
오픈소스인 OpenSSL 등의 버그로 인한 공격도 발생
- 에시 : 하트블리드 취약점 / 암호화 통신을 해독할 수 잇는 비밀키를 훔칠 수 있는 심각한 취약점 / 그 외 Open SSL 취약점 관련 상세 내용은 OpenSSL 공식 사이트에서 확인 가능


https://m.blog.naver.com/PostView.nhn?blogId=n_privacy&logNo=221412043898&proxyReferer=https%3A%2F%2Fwww.google.com%2F


TLS란,

서로 Protocol 버전과 암호화 할 키를 주고 받는 Handshake 단계,
실제 application 이 동작하는 단계,
Application 이 내용이 주고 받아지는 부분에서는 대칭키 암호화(symmetric cryptography)가 이루어지지만,
Handshake 단계에서는 모든 내용이 평문으로 주고 받게 된다. 

HMAC
메시지를 두 peer간 통신을 할 때 메시지의 내용이 손상될 수 있다. 메시지의 손상 여부를 파악하기 위해서 사용하는 기술이 MAC(Message Authentication Code) 이다. 그 중 TLS 에서는 HMAC(Hash Mac)이라는 방법을 사용.

만약 A라는 메시지의 내용을 보낸다고 가정하고, 송신 peer는 A를 수신 peer 와 합의한 Hash함수를 이용해서 hash값을 만들고 메시지 A에 hash 덧붙인 A를 보낸다. 이를 수신 측 peer 에서는 A와 Hash 값을 분리하고 A의 hash 값을 구한 뒤 받은 값과 비교해, 제대로 메시지가 도착했는지 검증


https://b.luavis.kr/server/tls-101


메시지 인증 (Message Authentication)
블록 단위로 암호화 된 메시지들이 상대방이 암호화 한 것이 맞는지 확인하기 위해서 무결성을 검증하게 되는데, 이 때 사용하게 되는 것이 메시지 인증(Message Authentication)

보통 MAC(Message Authentication Code)
- 해쉬 알고리즘을 이용하기 때문에 HMAC이라고 부르게 된다. 

송신자 / 수신자는 HMAC에 사용할 대칭키를 알고 있다. 
송신자는 암호화 메시지와 대칭키를 결합한 후, SHA 등의 해쉬 알고리즘을 이용하여 MAC을 추출하여 이것을 메시지와 함께 보낸다.

수신자도 암호화 메시지와 대칭키를 결합한 수, SHA 등의 해쉬알고리즘을 이용하여 MAC을 추출한다. 그 다음 송신자가 보낸 MAC과 수신자가 스스로 계산한 MAC을 비교하여 동일하면 암호화 메시지의 무결성에 문제가 없다고 판단

이렇게 6가지 항목을 이용하여 SSL/TLS 암호화 통신에 사용할 여러가지 알고리즘을 선태갛게 되며, 이러한 협의 및 선택된 알고리즘의 집합을 Cipher Suite라고 한다. 
https://rsec.kr/?p=455


SSL 

Netscape 사에서 만든 계층, 프로토콜로 웹서버와 브라우저 사이의 보안을 담당하는 역할을 맡고 있습니다. 
Certificate Authority(CA)라고 불리는 서드 파티로부터 서버와 클라이언트의 인증을 하는데 사용

SSL 인증서
SSL 인증서는 클라이언트와 서버 간의 통신을 제 3자가 보증해주는 전자화된 문서
웹 사이트가 믿을 만한가에 대한 지표
인증서는 트리(Tree) 구조를 이룬다. 

대칭키
-클라이언트와 서버 모두 동일한 키를 가지고 데이털르 암 /복호화 하는 방ㅅ기
-Private Key / Public Key를 이용한 암호화는 하나의 키로 암호화 하고 나머지 다른 하나로 복호화 하는 방식
- 앞에서 암호화한 키로만 암호화 할 수 있는 것이 아니라 반대 방향으로 복호화한 키로도 암호화할 수 있다. 

비대칭키 
- 클라이언트와 서버 모두 다른 키를 가지고 데이터를 암 / 복호화 하는 방식을 말한다. 하나의 키로 암호화를 하면 또 다른 키로 복호화를 할 수 있는 것을 말한다. 
- 즉, 하나의 키로 암 / 복호화를 할 수 없다. 
https://run-it.tistory.com/28?category=673442

TLS v.1.2 handshake overview
https://medium.com/@ethicalevil/tls-handshake-protocol-overview-a39e8eee2cf5

TLS v1.2 
Java 이용한 구현 https://www.verygoodsecurity.com/docs/security/tlsv12

AES 256으로 암호화

- AES 256 은 키가 256bit 즉 32 바이트 문자열
- 임의의 길이의 키 문자열을 받아서 랜덤 salt 를 첨가해서 해시하여 256 bit 키를 생성
- 암호화 모드는 CBC를 사용하고, 길이를 일정하게 하는데 PKCS5 패딩을 사용한다.

안드로이드 고급 암호화 표준(AES 256) 

C#으로 암호화 후 Java 에서 복호화하는 처리하는 샘플

해쉬함수
- 다양한 해쉬함수들이 존재하는데 흔히 많이 아는 MD5, SHA-512등이 잇다. 

단방향 해시 함수의 특징을 설명하면
- 수학적인 연산을 통해 원본 메시지를 변환하여 암호화된 메시지인 다이제스트 생성
- 암호화된 메세지로는 원본 메시지를 구할 수 없어야 하며, 이를 단반향성이라 한다.

암호화된 다이제스트로는 원본을 구할 수 없다. 단방향 해시 함수의 핵심
해시는 암호화를 하는데 많이 이용될 뿐, 그 자체가 암, 복호화를 위한 목적으로 만들어진 함수가 아니다. 즉, 복호화가 불가능하다.

해쉬함수는 어떠한 문제를 가지고 있는가?
1. 인식 가능성(recognizability)
- 동일한 메시지가 언제나 동일한 다이제스트를 가진다면, 공격자가 다이제스트를 많이 확보, 탈취하여 다이제스트와 원본메시지를 찾거나 동일한 효과를 메시지를 찾을 수 있음.
2. 속도 (Speed)
- 짧은 시간에 데이터를 검색하기 위한 것

Salting
- 단방향 해시 함수에서 다이제스트를 생성할 때 추가되는 바이트 단위의 임의의 문자열
- 이 솔트를 활용하여 원본 메시지에 문자열을 추가하여 다이제스트를 생성하는 것은 솔팅(Salting)이라고 한다.


단방향 해시 함수는 OTP (One-Time Password) 라고 생각하면된다. 
한번 생성했으면 다시는 복호화를 할 수 없다. 

대표적인 공격방식으로 사용자의 비밀번호 해시값과 동일한 해시값을 나타내는 공격이나 해시가 탈취당했을때 많이 비밀번호로 사용하는 문자열을 해싱하여 비교하는 두가지 공격이 두가지가 존재한다. 
- 솔팅과 키 스트레칭이 매우 중요하다. 

AES256 알고리즘이란

4가지 연산이 존재한다. 1개의 자리바꿈 연산과 3개의 치환 연산인데 다음과 같다. 

GF(2^8) 을 이용한 계산이란 기약 다항식

AED 키 스케줄링 알고리즘
STEP 1: 128 비트의 키를 4개의 32비트 워드로 바꾼다.
STEP 2: 

S-박스 : GF(2^8) 을 이용한 치환연산
행이동 (shift row) : 단순 자리 바꿈
열 섞음 (mix column) : GF(2^8)을 이용한 치환연산
라운드키 적용(add roundly) : XOR 연산을 이용

따라서 라운드 키를 적용하는 부분은 제외하고는 그 자체만으로 어떤 안전성도 제공하지 못한다. 
AES 알고리즘

상태
- AES 의 모든 연산들은 상태라고 하는 2차원 바이트 배열에 수행

AED 키 스케줄링 알고리즘
- AES 는 사용되는 암호키의 길이가 128 비트이면 총 44개의 32비트 워드로 확장되어 각 라운드마다 4개의 32비트 워드를 라운드 키로 사용한다. 

128 비트 키를 그림 4.7에 기술 된 것 처럼 4개의 32비트 워드로 바꾼다. 이 3개의 값이 첫 4개의 32비트 워드가 된다. 
단계 2. 첫 4개의워드 중 마지막 워드는 1 바이트 왼쪽 순환 이동된 뒤에 전방향 s-box을 이용하여 치환된다. 그 다음에 라운드 상수 XOR 된다. 결과 값은 첫 워드와 XOR 되어 다음 4개의 워드의 첫 워드가 만들어진다. 



AES는 블록 암호 작동 모드(block cipher mode of operation) 이 결합되어서 사용하는데 이는 비밀성이나 신뢰성과 같은 정보 서비스를 제공하기 위해 블록 암호를 사용하는 알고리즘

블록 암호 자체는 블록이고 하는 하나의 고정 길이 브트


중간에서 통신을 도청당해도 안전하고, 인젝션(Injection)과 같은 공격도 걱정할 필요가 없다. 다만 단점은 새로운 연결을 맺기까지 조금 느려진다. TLS는 처음 커넥션을 핸드세이크라 부르는 과정을 통해서 암호화 방식이나 

https://b.luavis.kr/server/tls-1.3
TLS 1.2 (RFC5246) 의 전체 핸드세이크 과정

22 port
Java 를 이용한 과정

Public key crypto systems that are comply used today (RSA, DHE, and a little bit of ECC). 
- RSA : cryptosystem / Diffie-Hellamn Key Exchange / Digital signature
https://www.siddharthkannan.in/tls-handshake/


TLS Handshake Flow
FUll Handshake 과정에 대한 전체 흐름은 아래 그림과 같고, 


Java 1.7 버전에서 TLSv 1.2 사용하기
System.setProperty(“https.protocols”,”TLSv1,TLSv1.1,TLSv1.2”);

Java 버전을 8버전으로 올리는 방법

https://m.blog.naver.com/PostView.nhn?blogId=cksdn788&logNo=220851759509&proxyReferer=https%3A%2F%2Fwww.google.com%2F


TLS / SSL 소개 및 Tomcat 에 HTTPS 적용하는 방법
TLS : Transport Layer Security
SSL : Secure Sockets Layers

- 웹 브라우저와 웹 서버 간의 통신을 안전하게 보장하는 기술이다.
- 데이터를 보낼 때 데이터를 암호화 하고, 데이터를 받을 때 암호화된 데이터를 복호화 하는 식의 기본 구조를 갖는다. 
- 이 통신 구조는 양방향 이기 때문에, 웹 부라우저와 웹 서버 모두 데이터를 내보낼 때 암호화를 진행한다. 

TLS / SSL 인증
- 웹 브라우저에서 암호화된 연결로 웹 서버와 통신하려고 하면, 웹 서버에서 브라우저에게 몇가지 증명서(Certificate)를 요구한다.
- 이 증명서는 클라이언트 인증 (client authentication)이라고 하며, 개인 사용자 간 보다는 B2B 형태에서 더 많이 사용된다.
- JSSE, APR 2가지가 있다. 
- JSSE : Java 런타임에서 제공
- APR : OpenSSL 엔진을 기본값으로 사용
https://joshuajangblog.wordpress.com/2016/09/02/tls-ssl-intro-and-tomcat-configuration/

https://qastack.kr/superuser/747377/enable-tls-11-and-12-for-clients-on-java-7
https://sarc.io/index.php/java/1306-ssl-tls-and-java-support-default
https://boxbop.tistory.com/97

https://chipmaker.tistory.com/entry/%E3%85%87
https://chipmaker.tistory.com/entry/TLSv12-RFC5246-%EC%A0%95%EB%A6%AC-2
https://www.google.com/search?q=aes+256&rlz=1C5CHFA_enKR823KR823&sxsrf=ALeKk03ID-xgWHOWqMLeVevktSiV9DFGUg:1584678294965&ei=lkV0Xv7DOov7wAOc_ZzgCw&start=20&sa=N&ved=2ahUKEwj-5urWmqjoAhWLPXAKHZw-B7w4ChDy0wN6BAgMEDE&biw=1113&bih=948

https://niceman.tistory.com/91
https://aircook.tistory.com/entry/AES-SHA-%EC%95%94%ED%98%B8%ED%99%94-1-JAVA?category=12207
https://aircook.tistory.com/entry/AES-SHA-%EC%95%94%ED%98%B8%ED%99%94-1-JAVA?category=12207
https://minsung-ee.tistory.com/5
https://g-y-e-o-m.tistory.com/148

https://offbyone.tistory.com/286

https://www.crocus.co.kr/1230

http://blog.naver.com/PostView.nhn?blogId=v_lovepooh_v&logNo=221317593465&parentCategoryNo=&categoryNo=14&viewDate=&isShowPopularPosts=true&from=search
https://soul0.tistory.com/510
http://www.packetinside.com/2010/01/%EB%B6%84%EC%84%9D%ED%95%A0-%ED%8C%A8%ED%82%B7-%EB%8D%B0%EC%9D%B4%ED%84%B0-%ED%81%AC%EA%B8%B0%EA%B0%80-%ED%81%B0-%EA%B2%BD%EC%9A%B0%EB%8A%94-%EC%9D%B4%EB%A0%87%EA%B2%8C-%ED%95%98%EC%9E%90.html

SSL 관련 Exception 해결하기
https://freestrokes.tistory.com/68

TLS(v1.2) -RFC5246 정리
https://chipmaker.tistory.com/entry/%E3%85%87
https://chipmaker.tistory.com/entry/TLSv12-RFC5246-%EC%A0%95%EB%A6%AC-2


Transport Layer Security (RFC 5246)
TLS 프로토콜의 목표는 우선순위에 따라서 다음과 같다. 
1. 암호학적 보안 : TLS 는 두개의 개체 사이에서 안전한 연결을 설립해야 한다.
2. 상호보완성 : 독립적인 프로그래머들은 다른 이들의 코드를 몰라도 암호 파라미터를 성공적으로 교환할 수 있는 TLS를 사용하여 애플리케이션ㅇ르 작성할 수 있어야 한다. 
3. 확장성 : TLS는 새로운 공개키와 대량 암호화 방법론이 필수적으로 통합 될 수있도록 하는 프레임 워크를 제공하고자 한다. 이것은 똫나 두개의 하위 목표를 달성해야하낟. 새로운 프로토콜을 만들 필요를 막아야 하며 전체적인 새로운 보안 라이브러리를 구현해야 할 필요를 피해야 한다.
4. 상대적인 효율성 : 암호화 작동은 매우 CPU 집중적인 경향이 있다. 특히나 공개키 연산에서 그렇다. 이러한 이유 때문에, TLS v

대칭키 (비밀키) 방식의 AES 256 

패딩( padding) 이란?
- 블록암호화를 진행하기 위해서는 패딩기법이 필요합니다. 데이터를 특정크기를 맞추기 위해서, 특정크기보다 부족한 부분의 공간을 의미없는 문자들로 채워서 비트수를 맞추는 것입니다. 암호화시엔느 반드시 필요한 방법입니다. 

Cipher c = Cipher.getInstance("AES/CBC/PKCS5Padding"); 

https://happy-hs.tistory.com/15

Related work paper
- Partially Encrypted Machine Learning using Functional Encryption
- CyptoDL : Deep Neural Networks over Encrypted Data
- CryptoNets : Machine Leanring Classification over Encrypted Data
- 2P-DNN : Privacy-Preserving Deep Neural Networks Based on Homomorphic Cryptosystem
- Machine Learning Classification over Encrypted Data
    - GELU-Net
    - CryptoNets
- Fully Homomorphic Encryption for Classification in Machine Learning

Deep Pack related survey page

https://programmingfbf7290.tistory.com/entry/10-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-%EC%89%AC%EC%9A%B4-SSL-%ED%86%B5%EC%8B%A0%EA%B3%BC-HTTPS-%EA%B8%B0%EB%B3%B8-%EC%9D%B4%EB%A1%A0

https://blog.hangadac.com/2017/07/28/%ED%99%88%EC%84%9C%EB%B2%84-%EA%B5%AC%EC%B6%95%EA%B8%B0-https%EC%99%80-ssl-%EC%9D%B8%EC%A6%9D%EC%84%9C-%EC%9D%B4%EB%A1%A0/

https://cheese10yun.github.io/https/
 https://victorydntmd.tistory.com/95
 https://aileen93.tistory.com/119
 https://run-it.tistory.com/29
 http://blog.daum.net/tlos6733/58
 https://zerodice0.tistory.com/51
 https://run-it.tistory.com/29
 https://wiki.wireshark.org/TLS
 https://sharkfesteurope.wireshark.org/assets/presentations17eu/15.pdf
 https://www.google.com/search?rlz=1C5CHFA_enKR823KR823&ei=v-ppXrWpJcai-QbE8bbQDA&q=fields+information+packet&oq=fields+information+packet&gs_l=psy-ab.3..33i160.4932.7863..8059...4.0..0.221.1724.0j12j1......0....1..gws-wiz.......0i7i30i19j0i10i19j0i30i19j0i10i30i19j0i5i30i19j0i30j0i10i30j0i5i30j0i8i13i30j0i8i30j33i21.JkEDY6_-Ow0&ved=0ahUKEwj1hOnRupToAhVGUd4KHcS4DcoQ4dUDCAs&uact=5
 https://ko.wikipedia.org/wiki/%EC%A0%84%EC%86%A1_%EC%A0%9C%EC%96%B4_%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C
 https://blackperl-security.gitlab.io/blog/2018/02/18/2018-02-18-codegate2018-miro/
 https://hoong2.tistory.com/entry/TLSpacket-export-certificate

 https://woonizzooni.tistory.com/entry/Wireshark-SSLTLS-%ED%8C%A8%ED%82%B7-%EB%B3%B5%ED%98%B8%ED%99%94
 https://www.google.com/search?q=tlsv1.2+openssl+%EC%A0%81%EC%9A%A9%ED%95%98%EA%B8%B0&rlz=1C5CHFA_enKR823KR823&ei=nglqXqexKaLxhwOps6f4Aw&start=20&sa=N&ved=2ahUKEwin-KWK2JToAhWi-GEKHanZCT84ChDy0wN6BAgMEDE
 https://qastack.kr/server/314858/how-to-enable-tls-1-1-and-1-2-with-openssl-and-apache
 https://web-obj.tistory.com/268
 https://happist.com/568683/%EC%87%BC%ED%95%91%EB%AA%B0-%EA%B5%AC%EC%B6%95%EA%B8%B0-ssl-tls-%EB%B3%B4%EC%95%88-%EB%93%B1%EA%B8%89-a%EC%97%90-%EB%8F%84%EC%A0%84%ED%95%98%EB%8A%94-lets-encrypt-%EC%9D%B8%EC%A6%9D/
 https://stih.tistory.com/52
 https://xinet.kr/?p=2012
 
 스마트 컨트렉트 
- 특정한 조건이 되었을때 동작하는 경우

Merkle Patricia Trie

Sha 2 -> 해시 표준화
Sha 3 -> 
KECCAK -> 모든 소프트웨어에서 효율성이 떨어진다.
Random X : 프로그램을 랜덤하게 만든다. 
Prove of W를 설계했구나.

무작위 프로그램이 생성된 경우 적합한 경우에만 프로그램만 실행
해당 전략이 유효한 이유 #1

무작위 프로그램은 Log -normal 분포를 따름

Verification time
- Proof of work 는 비신뢰 P2P 네트워크 구성을 위해 필요
- 네트워크 참여자들은 proof를 빠르게 검증할 수 있어야 함.
- 다만 검증 속도는 기존 기법과 유사한 정도로 유지해야 함.

ASIC 은 문제 바운더리를 명확하게 하는 경우에 확실하게 잘함
급속 연산 가능
새로운 연산 하는 시에는 구현하고 계산하는데 비효율적

Proof or work 알고리즘은 매우 큰 메모리 버퍼를 사용해야 함

컴퓨터가 메모리의 접근을 적게 할 수록 성능이 좋아짐.

Area-time (전체 시스템 크기)
JAVA 어떤 라이브러리 든지 모든 컴퓨터에서 가능하게 만듬

ssl.PROTOCOL_TLSv1_2
    - 채널 암호화 프로토콜로 TLS 버전 1.2를 선택. 이것은 가장 현대적인 버전, 양측이 모두 가능하다면 최대한의 보호를 위해 아마도 제일 나은 선택
    - Openssl 버전 1.0.1+에서만 사용할 수 있습니다. 

OpenSSL은 모든 버전 특정 프로토콜을 폐지했습니다. 대신 OP_NO_SSLv3와 같은 플래그와 함께 기본 프로토콜 PROTOCOL_TLS를 사용하십시오.
https://docs.python.org/ko/3/library/ssl.html


소캣 생성

SSLSocket 객체로 소켓을 포장하기 위해 SSLContext 인스턴의 SSLContext.wrap_socket()을 사용하는 것이 좋다. 
도우미 함수 create_default_context()는 보안 기본설정의 새 컨텍스트를 반환

기본 컨텍스트와 IPv4/IPv6 이중 스택을 사용하는 클라이언트 소캣 예제

import ssl

hostname = 'www.python.org'
context = ssl.create_default_context()

with socket.create_connection((hostname, 443)) as sock:
    with context.wrap_socket(sock, server_hostname=hostname) as ssock:
        print(ssock.version())


사용자 정의 컨텍스트와 IPv4를 사용하는 클라이언트 소캣 예제

hostname = 'www.python.org'
# PROTOCOL_TLS_CLIENT requires valid cert chain and hostname
context = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
context.load_verify_locations('path/to/cabundle.pem')

with socket.socket(socket.AF_INET, socket.SOCK_STREAM, 0) as sock:
    with context.wrap_socket(sock, server_hostname=hostname) as ssock:
        print(ssock.version())


Localhost IPV4에서 리스닝하는 서버 소켓 예제:
context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
context.load_cert_chain('/path/to/certchain.pem', '/path/to/private.key')

with socket.socket(socket.AF_INET, socket.SOCK_STREAM, 0) as sock:
    sock.bind(('127.0.0.1', 8443))
    sock.listen(5)
    with context.wrap_socket(sock, server_side=True) as ssock:
        conn, addr = ssock.accept()


ctx = ssl.create_default_context(purpose=Purpose.SERVER_AUTH, cafile=None, capath=None, cadata=None)
ctx.option &= ~ssl.OP_NO_SSL_v3


https://docs.python.org/ko/3/library/ssl.html


Cryptographically secure pseudorandom number generator
https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator