암호화 및 https
HTTPS
SSL 인증서는 클라이언트와 서버간의 통신을 제 3자가 보증해주는 전자화 된 문서. 클라이언트가 서버에 접속한 직후 서버는 클라이언트에게 이 인증서 정보를 전달. 클라이언트는 이 인증서 정보가 신뢰할 수 있는 것인지 검증 한 후에 다음 절차 수행. 즉, 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지를 보장하는 역할. 어떻게 그 역할 보장? CA(certificate authority, root certificate) - symantec, comodo, godaddy, globalsign 등등.. 클라, 서버간 보안 채널을 만듬
기능
- 클라이언트가 접속한 서버가 신뢰 할 수 있는 서버임을 보장
- 그 서버가 SSL 통신에 사용할 공개키를 클라이언트에게 제공한다.
이점
- 통신 내용이 공격자에게 노출되는 것 방지
- 클라이언트가 접속하려는 서버가 신뢰할 수 있는 서버인지 판단
- 통신 내용 악의적인 변경 방지
</br> </br>
https://livvy.byb.kr/posts/hello-tls-1-3/
대칭키
암호화 할 때 사용하는 일종의 비밀번호를 키(Key) 라고 한다. 이 키에 따라 암호화된 결과가 달라지기 때문에 키를 모르면 복호화를 할 수 없다. 대칭키는 동일한 키로 암호화 복호화를 같이 할 수 있는 방식의 암호화 기법. 예를 들어, 암호화 할 때 1234라는 값을 사용했다면, 복호화 할 때도 1234값을 입력해야 한다.
문제점 - 키 값 또한 대상에게 전송해야함. 이 과정에서 키가 노출 될 수 있음.
DES AES 같은 것들이 있음
</br>
공개키(PKI)
키가 2개. A키로 암호화를 하면 B키로 복호화 할 수 있고, B키로 암호화하면 A키로 복호화 할 수 있는 방식 비공개키, 공개키 가 있음. 공개키로 암호화하고 비공개키로 복호화 : 이는 공개키가 탈취당해도 상관없음. 어차피 비공개키가 없으면 복호화 할 수 없기 때문.
RSA 같은 것들이 있음
해시 함수의 결과 : 해시 값 혹은 메시지 다이제스트 ex) MessageDigest.getInstance(“SHA-256”) -> sha-256을 해시 알고리즘으로 사용하겠다
Base64인코딩 - binary data를 text로 변경하는 인코딩. ASCII 문자들로 표시할 수 있는 가장 큰 진법. 바이너리 데이터 손실을 막음.
루트 인증서는 Android N에 약 150 개가 포함 된 Android 장치에 사전 설치됩니다.
leaf certificate - https://stackoverflow.com/questions/43605755/whats-the-leaf-certificate-and-sub-certificate-used-for-and-how-to-use-them
tls버전을 클라에서 먼저 서버에게 알려줌.
X509TrustManager -> ca인증서 관련 체크??
Salting
해시 함수에서 다이제스트를 생성할 때 추가되는 바이트 단위의 임의의 문자열. ex)”helloworld”라는 원본 문자에 “Dp5BnBuJzdKr3DpE” 솔팅을 사용하여 다이제스트를 생성할 수가 있다. Dp5BnBuJzdKr3DpE(salt) + helloworld (plainText) -> (Hash Function) -> DIGEST
공격자는 솔트도 알아야해서 보안이 강화됨. 솔트가 각 패스워드 마다 다를 경우 더욱 알아내기 힘듬.
ex)
//해당 키를 가지고 Salt 생성 후 SHA512 적용하여, 다이제스트 생성
MessageDigest digest = MessageDigest.getInstance("SHA-512");
byte[] keyBytes = password.getBytes("UTF-8");
byte[] saltBytes = digest.digest(keyBytes);
// in Java (65536번 해싱)
PBEKeySpec pbeKeySpec = new PBEKeySpec(password.toCharArray(), saltBytes, 65536, 256);
Key Stretching
빠른 해시함수의 속도로 취약점이 발생한다면, 초기 다이제스트 생성 시 해시함수를 반복(Iteration)하여 시간 소요가 걸리게 하자 무차별 대입으로 부터 패스워드 추측을 힘들게 하기 위함.
Adaptive Key Derivation Functions
KDF란? 키를 파생시키는 함수. 여기서 Adaptive Key Derivation Function은 다이제스트를 생성할 때 솔팅과 키 스트레칭을 반복하여, 솔트와 패스워드 외에도 입력 값을 추가하여 공격자가 쉽게 다이제스트를 유추할 수 없도록하고, 보안의 강도를 선택하는 Adaptive한 매커니즘을 KDF에 추가한 함수라고 볼 수가 있다.
ex) PBKDF2
내가 뒤에서 보여줄 소스도 PBKDF2를 사용하여, 만든 키와 IV(초기화벡터)를 사용한다. 먼저, PBKDF2는 가장 유명한 AKDF로, 솔트를 적용한 후 해시 함수의 반복 횟수를 임의로 선택할 수 있다. SHA와 같이 검증된 해시 함수만을 사용한다.
PBKDF2의 기본 파라미터는 5가지 이다.
DIGEST = PBKDF2(PRF, Password, Salt, i, DLen);
PRF : 난수 (ex : HMAC) Password : 패스워드 Salt : 위에서 설명한 솔트 i : Iteration(반복) 횟수 DLen : 원하는 다이제스트 길이
AES
대칭키. 키 한개. AES-128,192,256 => 암호할 키의 길이 각 암호는 각각 128, 192 및 256비트의 암호화 키를 사용하여 128비트 블록 사이즈의 데이터를 암호화하고 해독합니다. 각 타입에 따라,라운드 횟수가 다르다. 라운드는 암호를 어렵게 만들기 위해 섞고, 대체하고, 바꾸는 작업들.
- IV-Initialization vector
IV는 똑같은 비밀키로 여러번 암호화 한 값이 항상 같지 않게되도록 함. IV는 반복적이지 않고 무작위적이여야 함. AES itself does not directly use a salt (or indeed, an IV). (AES상에서 솔트)The salt is used so that the same password does not always generate the same key An IV similarly ensures that the same plaintext does not produce the same ciphertext https://stackoverflow.com/questions/1949640/does-iv-work-like-salt
- Modes
mode는 암호화 하는데 어떤 알고리즘 사용되는지를 말한다.
종류 :
CBC AESMode.cbc CFB-64 AESMode.cfb64 CTR AESMode.ctr ECB AESMode.ecb OFB-64/GCTR AESMode.ofb64Gctr OFB-64 AESMode.ofb64 SIC AESMode.sic
- Padding
암호화 과정을 진행할 때, 먼저 암호화 하는 값에 대해 pad를 진행하는 것을 알 수 있다. 이것은 블록 싸이즈 컨셉이랑 연관 있음(128). 정해진 길이를 맞춰야하고 안그러면 작동하지 않음. pad는 이러한 길이를 맞춰주기 위해 빈 바이트를 넣는 과정.
https://ricardo-castellanos-herreros.medium.com/secure-your-sensitive-data-with-aes-in-flutter-63b747e1fd7e