오늘은 어디로 갈까...

네트워크 보안에 대한 단상 본문

낙서

네트워크 보안에 대한 단상

剛宇 2009. 12. 30. 10:26

 가져다 쓰면 편할것을... 생각해내서 만들어 쓰는것은 머리를 아프게 한다. 하지만, 이게 재미있으니... 어쩔수 없지.
 Client <-> Server 간에 안전한 통신을 하기 위해서는 어떻게 해야할까?
 아주 간단히 생각한다면 대칭키 암호화 알고리즘을 사용해서 데이터를 교류하면 될것이다. 그런데 대칭키 암호화를 사용할려면 동일한 비밀키를 C/S 두군데 가지고 있어야한다. 문제는 누군가가 이 비밀키를 알게 될 경우(만든 사람은 안다~~ ㅋㅋㅋ), 또는 클라이언트가 해킹당해서 비밀키가 누출되면... 모든 데이터에 빵꾸~~가 난다는 것이다. 거기다 꼬리가 길면 밟힌다고, 동일한 비밀키를 오래쓰면, 암호해독법에의한 공격에 취약해지기 마련이라서, 대칭키 암호화에 사용되는 비밀키는 단기간의 세션(SessionKey) 형태로 사용하는게 바람직할것 같다.
 그렇다면, 이 비밀키를 생성한후 C/S간에 공유하기 위한 키 교환 메커니즘이 필요하게 되는데, 만만한게 비대칭키 암호화 알고리즘이다. 수신자의 공개키로 암호화하여 보내면, 송신자의 개인키로 복호화한 후 사용하면 되는것이다.
 그럼, 누가 수신자 역할을 해야하는가? 서버? 클라이언트? 아니면 둘다?
 첫째, 서버가 수신자 역할을 한다고 가정하면, 클라이언트가 송신자 역할을 한다. 즉 클라이언트가 개인키를 가지게 되는데, 문제는 클라이언트는 해킹당하기 쉬워서 개인키가 누출될 수 있다는 위험성이 도사린다.
 둘째, 클라이언트가 수신자 역할을 한다고 가정하면, 서버가 송신자 역할을 한다. 서버가 개인키를 가지게 되는데, 서버가 해킹당할경우 볼장다본경우라서 논의할게 없고, 클라이언트가 대칭키 암호화에 사용할 비밀키(세션키)를 암호화해서  서버에게 주면, 서버를 그 비밀키를 복호화해서, 해당 비밀키로 데이터를 교류하면 된다. 이럴 경우 문제가 없을까? 데이터 자체는 암호화되어서 제3자가 알아 볼수는 없지만, 데이터를 그대로 재사용할가 있다는것이다. 간단히 예를 들면, 로그인을 할 경우 사용자의 아이디와 비밀번호를 포함한 데이터가 암호화되어서 "0b8b61c936ad65943a4d01e777c"란 데이터가 서버로 날아간다고 하자, 제 3자는 그 사용자의 아이디와 비밀번호는 알 수 없지만, 동일한 데이터 즉, "0b8b61c936ad65943a4d01e777c"을 서버에 날리면 로그인을 할 수 있다는 것이다. 물론 받아오는 데이터도 암호화되어 있다면 알아볼 수 없겠지만, 뭔가 찜찜한것은 사실일것이다.(쓸데없는 생각인가..? -_-;)
 그렇다면 어떻게 해야하는것일까? 대칭키 암호화에 사용할 비밀키를 서버에서 만들어서 클라이언트에 넘겨주면 되는것이다.
 흠..
 일단 클라이언트에서 비밀키를 암호화해서 서버에 넘겨주면, 서버는 새로운 비밀키를 생성한후, 복호화한 비밀키를 가지고 암호화한후 클라이언트에게 넘겨준다. 그럼 넘겨받은 데이터를 자신의 비밀키를 가지고 복호화하면, 상호 통신에 사용할 비밀키를 획득하게된다. 음 뭔가 이상한것 같기도하고..
 다시 원점으로 돌아가보자.
 이전에 말한 첫번째 방법, 즉 클라이언트가 개인키를 가지는 방법인데, 개인키의 누출의 위험이 있으므로 각 클라인언트별로 실행시 키를 랜덤하게 생성하게 하면 될거 같다. 이럴 경우 발생할 수 있는 또다른 문제는 서버가 진짜 서버인지 판단할수 있는지 여부인데, 이건 두번째 방법, 즉 서버가 개인키를 가지게 하고, 클라이언트가 그 공개키를 가지게 하여 인증하면 될거 같다.
아 머리가 아프다... 뭔가 좀 더 멋드러진 방법이 없는것일까...?