From 17569f209e42dfd82daf915d0ed0b6459593ca5d Mon Sep 17 00:00:00 2001 From: Yongho Choi Date: Sun, 27 Aug 2017 20:27:09 +0900 Subject: [PATCH] =?UTF-8?q?=EC=95=94=ED=98=B8=ED=99=94=20=EA=B4=80?= =?UTF-8?q?=EB=A0=A8=20=EB=82=B4=EC=9A=A9=20=EC=A0=95=EB=A6=AC?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../\354\225\224\355\230\270\355\231\224.md" | 115 ++++++++++++++++++ 1 file changed, 115 insertions(+) create mode 100644 "md/Security/\354\225\224\355\230\270\355\231\224.md" diff --git "a/md/Security/\354\225\224\355\230\270\355\231\224.md" "b/md/Security/\354\225\224\355\230\270\355\231\224.md" new file mode 100644 index 0000000..0b89668 --- /dev/null +++ "b/md/Security/\354\225\224\355\230\270\355\231\224.md" @@ -0,0 +1,115 @@ +# 대칭키 (공통키) + +* 암호화와 복호화에 동일한 키를 사용 +* 부하가 적음 +* 키가 유출되면 누구나 복호화 할 수 있다는 단점이 존재 +* 키 관리가 어려움 + * A와 B가 통신 할 경우 C가 키를 알면 안되므로 A와 B간 통신에 필요한 키와 A와 C가 통신을 하기 위한 키가 따로 필요 + * 유저가 늘어날 수록 키의 개수도 늘어남 + + + +# 비대칭키 (공개키) + +* 암호화와 복호화에 각기 다른 키를 사용 +* 공개키를 통해 외부에서 암호화를 하고 이 데이터를 받은 서버는 비밀키로 복호화. + * 그래서 공개키는 제 3자가 봐도 상관 없지만 비밀키는 절대 노출되면 안됨. + + + +## RSA 암호 + +* 큰 숫자의 소인수분해가 힘들다는 것을 이용 + * 15를 소인수분해해서 3 * 5라는 결과를 얻는 것은 쉬움 + * 10,001을 소인수분해 한다면 73 * 137이라는 결과가 나오는데 시간이 오래걸림. + * 자릿수가 늘어날 수록 소인수분해가 매우 풀기 어려운 문제가 된다라는 사실을 이용한 것이 공개키 암호 +* 작은 데이터 암호화에 적합 + * 공개키 암호는 공통키 암호보다 복잡한 계산을 해야하기 때문에 부하가 커진다. + * 공통키 암호와 같은 중요한 데이터를 전송할 때 사용. + + +* 공개키 방식의 암호화 작업은 너무 느려서 키의 크기보다 큰 데이터는 암호화 해주지 않는다. + + * 키사이즈가 2048인 경우 이를 바이트로 환산하면 2048/8 = 256 바이트, + * 암/복호화 이외의 팩터 때문에 전부를 암/복호화 할 수 없음. 그래서 -11 바이트를 해서 245바이트 만큼의 데이터까지만 암호화를 해준다. + +* 2010년 기준으로 2048비트 이상의 길이를 가진 키를 사용할 것을 권장 + + * 현재 발행되는 대부분의 증명서는 2048 비트 + + ​ + +# 해시 + +* 해시에는 키가 존재하지 않는다. +* 동일한 입력에 대해서는 항상 같은 문자열이 출력 + * 한글자라도 바뀌게 되면 출력되는 암호문이 크게 바뀜 +* 암호문을 평문으로 다시 복호화하는 것이 불가능 +* 단방향 함수 또는 메시지 다이제스트 함수라고도 불림 + + + +## 특징 + +1. 해시 함수를 적용한 결과로부터 원래 메시지를 추정할 수 없다. +2. 메시지의 길이에 상관없이 해시의 값은 일정하다 +3. 동일한 해시 값을 가지는 다른 메시지를 작성하기는 힘들다. + + + +## 사용 예 + +1. 사용자 패스워드 저장 + * 패스워드를 저장하는 서버조차 패스워드를 알면 안되므로 저장 시 패스워드를 해시로 암호화 + * 유저는 동일한 패스워드를 입력할 경우 동일한 해시로 변환되기 때문에 서버가 패스워드의 평문을 몰라도 인증이 가능해짐 + * 서버에서 패스워드가 유출되더라도 유저가 직접 입력한 패스워드의 유출을 막을 수 있음 +2. 파일이 깨졌는지 확인 + + + +## 함수 + +- MD5 (Message Digest 5) : 원래 문장으로부터 128비트의 값을 생성 +- SHA-1(Secure Hash Algorithm) : 원래 문장으로부터 160비트의 값을 생성 + + + + + +# 게임에서의 암호화 + +* 가장 완전하다는 전자서명 방식은 CPU 부하가 크기 때문에 적합하지 않음 +* 대부분 RSA 방식이나 Diffie-Hellman 방식의 키 교환 방식으로 비밀키를 공유하고, 그것을 세션이 살아 있는 동안 계속해서 사용하도록 구현. + * 이는 Man in the middle 공격의 리스크를 대폭 낮춤. + * 하지만 리스크를 완전히 없애는 것은 포기 +* 암호화와 병행하여 적절한 알고리즘으로 압축을 사용하면 트래픽을 50% 정도 삭감할 수 있다. + * 압축률을 올리기 위해서는 압축을 한 뒤에 암호화를 해야한다. + + + +## Man in the middle (MITM, 중간자) 공격 + +* 제 3자가 통신의 중간에 들어가는 방법을 통한 공격 + + + +### MITM의 원리 + +1. A와 B가 네트워크를 통해 데이터를 주고 받을 때 공격자가 중간에 들어간다. +2. A는 B와 통신을 하는 것으로 알지만 공격자와 통신을 하게 됨 +3. B 또한 A와 통신하는 줄 알지만 공격자와 통신을 함 +4. A가 B에게 정보를 발송할 때 A는 B의 공개키로 암호화를 하려 한다. +5. A는 공격자의 공개키를 B의 것이라고 착각하고 이 공개키로 암호화해서 발송한다. +6. 공격자는 A가 발송한 데이터를 본인의 비밀키로 복호화한다. + * A에게 공격자의 공개키를 전달했으므로 공격자의 비밀키로 이를 복호화 할 수 있음 +7. 공격자는 데이터를 변조 후 B에게 받은 공개키로 다시 암호화하여 B에게 전달한다. +8. B는 자신의 비밀키로 이를 복호화함으로써 A로부터 직접 정보를 얻었다고 판단하지만 실제로는 공격자로부터 변조된 데이터를 받은 것이 된다. + + + +# 참고 + +* [MITM(Man In The Middle) Attack?](http://blog.daum.net/mom0245/29) +* [조금 어정쩡 하지만 어정쩡하게 좋은 암호화 방식 PGP #2](http://www.gamedevforever.com/156) + +