일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 보안
- 진단항목
- 안드로이드
- WEB
- network
- ASP.NET
- ubuntu
- Lenovo D330-10igm
- HTML5
- 인증 및 세션관리
- 네트워크
- 인테리어
- retropie
- 이보드
- Web Programming
- 고전게임
- 피들러
- 셀프인테리어
- 고전게임기 만들기
- D330-10igm
- 우분투
- D330
- 웹
- 자바스크립트
- c#
- 한컴오피스
- fiddler
- 단열
- 윈도우 8
- 문자열
- Today
- Total
Kinesis´s Open Document
진단항목 : 안전한 인증 및 세션 관리 - 통신과정 #02 본문
※ 최대한 이해하기 쉽게 서술하고자 하였으나 보안 지식은 기초라 할지라도 일반적인 기초 과정보다 높은 수준을 필요로 합니다.
※ 본 내용은 초안이며, 저작권은 저 Kinesis(Hae Kwang, Kim) 에게 있으므로 무단으로 펌하여 재배포하는 것을 금지합니다. (단, 본 게시물의 일부만을 발췌하여 출처 주소를 남겨 본 게시물에 접근할 수 있는 링크를 남기는 경우는 허용합니다. 이는 제가 여러분들을 믿고 양질의 게시물을 작성하고 여러분들은 접할 기회를 제공받기 위한 서로의 배려입니다.)
※ 본 내용은 보안 기초를 학습하는 사람이나, 개발자들에게 유용할 수 있습니다.
최종본 바로보기
통신과정에서의 두 번째 이슈는 바로 이 암호화 통신에서 발생한다. 첫 번째 이슈를 해결하기 위해 대응방안으로 암호화 방식을 도입하는 과정에서 고려해야 할 사항이 추가되는 것이다. 클라이언트와 서버가 암호화 통신을 하기 위해서는 서로간에 사전에 약속된 암호화 방법에 대한 규격(또는 암호화키)이 있어야 한다. 이를 위해서 클라이언트와 서버는 불가피 하게 첫 번째 연결에서 앞으로의 암호화 방법에 대한 규격(또는 암호화키) 정보를 주고 받아야 한다.
문제는 클라이언트와 서버는 물리적으로 떨어져 있기에 암호화를 위한 규격(또는 암호화키)에 관련한 내용조차 전달자를 거쳐야 전달이 된다는 것에서 발생한다. 즉 만약에 전달자가 클라이언트와 서버간 암호화 통신을 위해 주고 받은 암호화 규격까지 도청한 경우 전달자는 암호화 및 복호화 과정을 스스로 거쳐 암호화를 통해 보호해 둔 메시지의 원본을 확인 할 수 있게 되는 것이다.
비 전공자를 위한 추가 서술
이해하기 쉽게 풀어 설명해서 내가 친구A와 비밀스러운 편지를 주고 받으려고 하는데 우편이 분실되거나 배달원이 내용을 훔쳐보는 만약의 일을 대비해 내용을 암호화 하려 한다. 문제는 이 편지를 받을 친구A와 사전에 "내가 어떤 암호를 보내면 어떻게 풀면 원래의 내용을 알 수 있을거야 그리고 네가 보낼때도 이렇게 해서 작성해서 보내" 라고 규칙을 합의를 본 것이면 문제가 되지 않으나 이러한 암호화 및 복호화에 관한 서로의 약속이 없이 한 쪽에서 일방적으로 암호화된 내용을 보내면 상대방은 내용을 알 수가 없으니 내용을 이해할 수도, 기대한 답변을 받을 수도 없는 상황이 발생하게 된다.
이때 사람과 컴퓨터 간의 차이가 발생하게 되는데, 사람인 우리는 당사자에게 찾아가서 "이건 뭐라고 보낸거야" 라고 물어 답변을 받거나, 앞으로의 암호화 및 복호화에 대한 규칙을 확인 할 수 있겠지만 컴퓨터는 스스로의 의지에 의해 움직여 확인하는 것이 불가능하다.
예를 상황을 들어 생각해보자. 어떠한 사정으로 내가 상대방을 찾아갈 수 없는 상태이며 서로 사전에 암호화 및 복호화 방법에 대해 약속한 것이 없다. 그러나 앞으로 상대방과 암호화 및 복호화 방식을 정해 해당 방식을 이용해 메시지를 주고 받고자 한다. 어떠한 방법으로 암호화 및 복호화 방식을 전달할 수 있을 것인가? 사실 여기서 우리가 선택할 수 있는 경우의 수는 많지 않다 바로 평소에 이용하던 전달자를 통해 암호화 및 복호화 방법을 기술한 메시지를 보내는 방법 밖에는 없는 것이다. 그리고 이 때, 이 방법을 우연치않게 또는 고의적으로 전달자가 알게 된다면 이후에 암호화하여 보내는 내용은 이미 방법을 아는 전달자에겐 더 이상 암호화된 메시지라고 할 수 없다.
이러한 문제를 완화시키기 위한 방법으로 암호화 규격(또는 암호화키)을 실시간 또는 일정 간격을 기준으로 갱신하는 방법과 클라이언트와 서버가 각각 다른 부분의 부분키를 가지고 있고 서로가 넘겨주는 값중 일부에 자신이 가진 부분키를 포함하여 전달하여 전달받은 부분키와 결합시켜 암호화 및 복호화를 하는 방법이 있다. 결과적으로 이 방법의 핵심은 한번에 키가 노출되지 않는 것에 목적을 가지고 있다.
비 전공자를 위한 추가 서술
다시 좀 더 이해하기 쉽게 설명을 덧붙이자면, 앞서의 예에서 암호화 및 복호화 방법이 전달자에게 직접적으로 노출될 가능성을 낮추고 좀 더 안전하게 암호화 규격(또는 암호화키)를 만들어 쓰는 방법은 무엇일까? 바로 직접적인 방법을 서술하는 것이 아닌 간접적 방법을 이용한 서술을 고려할 수 있다. 요컨데 "앞서 이전에 내가 보낸 어떠한 메시지들과 몇 번째의 내용을 내가 보낸 어떠한 메시지와 합쳐 암호화 및 복호화 해라" 라고 전달하는 방법이다. 즉, 어떠한 방법을 쓰더라도 전달자라는 매체를 경유를 해야만 하는 절대적인 조건에서 안전하게 암호화 및 복호화 방법을 교환하는 방법은 결국 한 번에 노출되지 않도록 신경 쓰는 것 밖에 없다는 이야기다.
그 외에도 각각 암호화 방식에 따라 발생되는 이슈의 차이가 있기는 하나, 근원적으로 클라이언트와 서버 사이에 암호화 규격(또는 암호화키)를 주고 받아야 하는 과정을 없애는 것이 불가능하기 때문에 이를 어떻게 노출이 쉽지 않게 만들고 관리할 것인지를 확보하는 것이 공격을 예방하는데 있어 매우 중요한 포인트가 된다고 말할 수 있다.
'기획 시리즈 > 보안 : 진단항목 이해하기' 카테고리의 다른 글
진단항목 : 안전한 인증 및 세션 관리 - 보관과정 #02 (0) | 2016.06.29 |
---|---|
진단항목 : 안전한 인증 및 세션 관리 - 보관과정 #01 (0) | 2016.06.29 |
진단항목 : 안전한 인증 및 세션 관리 - 처리과정 #03 (0) | 2016.06.28 |
진단항목 : 안전한 인증 및 세션 관리 - 처리과정 #02 (0) | 2016.06.28 |
진단항목 : 안전한 인증 및 세션 관리 - 처리과정 #01 (0) | 2016.06.28 |
진단항목 : 안전한 인증 및 세션 관리 - 통신과정 #01 (0) | 2016.06.21 |