1. 네트워크 보안 4대 요소

  • confidentiality: 센더와 리시버 사이 통신 내용을 제3자가 보고 알 수 없어야 한다. (센더는 메시지를 암호화 해서 전송하고, 리시버는 이를 해독하여 메시지를 수신한다.)

  • authentication: 센더와 리시버는 서로가 상대라는 것을 인증할 수 있어야 한다.

  • message integrity: 센더와 리시버는 전송된 메시지가 도중에 변경되지 않음을 확신할 수 있어야 한다.

  • access and availability: 제3자의 공격 등으로 네트워크 통신이 중단되지 않고 센더와 리시버는 언제든지 통신할 수 있어야 한다.

- 현재 인터넷의 프로토콜 체계인 TCP/IP를 만들 당시에는 네트워크 보안 위험이 고려되지 않았기 때문에 위와 같은 요소들이 구현되지 않았고, 현재까지 관련 이슈가 나타날 때마다 그때그때 패치를 하는 식으로 문제를 해결해오고 있다.

2. confidentiality

1) symmetric key cryptography

- 어떤 메시지를 암호화를 할 수 있고 또 그 암호화된 메시지를 해독할 수 있는 키가 미리 정해져 있을 때, 그 키를 알고 있는 센더는 그 암호화 키로 메시지를 암호화 해 전송하고 또 그 키를 알고 있는 리시버는 그 암호화 키로 메시지를 해독해 그 내용을 얻는 방식을 말한다. AES, DES 등이 이러한 방식에 해당한다.

- 이 방식으로 암호화 통신을 하려면 사전에 센더와 리시버가 미리 암호화 키를 합의해야 한다. TCP connection이 구축된 다음에 센더가 키를 리시버에게 암호화하지 않고 전송한다면 그 키가 제3자에게 유출될 위험이 있으므로 일반적인 인터넷 환경에서는 단순히 이 방법만 써서는 암호화 통신이 보장이 안 된다.

2) public key cryptography

- 어떤 메시지를 암호화하는 키는 공공연히 알려져 있되(public key) 그 키로 암호화된 메시지를 해독할 수 있는 키는 오직 리시버만 갖고 있어(private key) 센더는 그 public key로 메시지를 암호화 해 전송하고 리시버는 자신의 private key로 메시지를 해독해 그 내용을 얻는 방식을 말한다. RSA 등이 이러한 방식에 해당한다.

- 이 방식은 메시지를 암호화하고 해독하는 데 symmetric key 방식보다 훨씬 더 많은 자원을 사용하므로, 센더-리시버 사이 오가는 모든 메시지를 이 방식으로 암호화하고 해독한다면 네트워크 통신 효율이 많이 떨어지게 된다. 일반적인 인터넷 환경에서는 보통 symmetric key 방식으로 암호화 통신을 하되, symmetric key 방식에서 사용할 암호화 키를 public key 방식으로 리시버에게 전송하는 방식을 사용한다. (SSL/TLS 등이 이러한 방식에 해당한다.)

- 이 방식을 사용할 때 주의할 점이, 센더가 암호화할 때 쓰는 public key가 정말로 리시버의 public key여야 한다는 것이다. 제3자가 자신이 센더의 메시지를 수신해야 할 리시버라고 주장하며 리시버의 public key 대신 자신의 public key를 센더에게 알려주면 센더는 엉뚱한 제3자의 public key로 메시지를 암호화하게 되고, 결국 원래 메시지를 수신해야 할 리시버는 그 메시지를 해독하지 못하고 제3자가 그 메시지의 내용을 알게 된다. 따라서 이 방식에서는 센더 측에서 ‘내가 메시지 보내는 상대의 public key는 이것이다’ 하는 정보를 정확히 아는 것이 매우 중요한 문제가 된다. 실제 인터넷에는 실제 유명 웹사이트들의 public key가 정확히 무엇인지를 확인하고 증명해주는 유명 인증기관(certificate authority, CA)이 여럿 있으며, 또 실제 인터넷에 접속하는 사용자들이 그 인증기관의 public key를 정확히 아는 것 또한 중요한 문제이므로, 실제 사용자들이 사용하는 브라우저들에는 유명 인증기관들의 public key가 프로그램 소스코드 안에 들어가 있어 인터넷 보안의 confidentiality를 구현하고 있다.

3. authentication

- 예를 들어 Alice라는 호스트가 Bob이라는 호스트에게 자신이 Alice임을 인증받고 통신을 하고 싶다 할 때, Alice가 단순히 메시지에 자신의 IP 주소와 함께 ‘내가 Alice다’라는 주장만을 담아 전송하는 것으로는 Bob이 그 센더가 진짜 Alice인지를 알 수 없다. 일반적인 TCP/IP 환경에서는 제3자가 패킷에 임의로 ALice의 IP 주소를 넣고 ‘내가 Alice’라는 메시지를 담아 전송하는 게 가능하기 때문이다.

- Bob이 센더가 Alice임을 확인하기 위하여 다음과 같은 방법을 사용한다.

1) Bob은 무작위로 숫자를 하나 골라 전송한다.

2) Alice는 Bob이 전송한 숫자를 자신이 갖고 있는 암호키로 암호화해 그 값을 리턴한다.

3) Bob은 Alice가 리턴한 값을 해독한다. 그 값이 Bob이 전송했던 숫자와 같다면 센더가 갖고 있는 암호키가 Alice의 암호키가 맞다는 뜻이므로 이로써 센더가 Alice임이 증명된다.

4. message integrity

- 상기한 방식을 사용하면 리시버가 수신한 메시지가 센더가 보낸 메시지가 맞고 그 내용도 중간에 제3자의 공격 등으로 변경되지 않았음이 보장되나, 센더가 매번 메시지 전문을 위 방식으로 암호화해 전송한다면 소모되는 자원이 매우 커지게 된다. 일반적으로는 보낼 메시지와 함께 그 메시지에 대하여 MD5, SHA 등의 해시함수를 사용한 해시값을 public key cryptography 방식으로 암호화해 이 값을 전송한다.

- 리시버는 (1)수신되는 메시지를 센더가 사용했을 해시함수를 사용하여 해시값을 구해보고 (2)그것이 센더가 보낸 해시값과 일치하는지 여부를 검사하여 message integrity 보장 여부를 알 수 있다. (이처럼 메시지를 해시함수로 처리한 해시값을 암호화하는 방식을 message digest라 한다.)

5. SSL/TLS과 HTTPS

- TCP/IP의 application 계층 이외 계층에는 소켓을 통해 전송하는 메시지에 대한 별도의 암호화 처리 절차가 없어 특별한 조치 없이 메시지를 application 계층 아래로 내보내면 제3자의 공격에 무방비로 노출된다. 이러한 문제를 해결하기 위해 1995년 처음으로 인터넷 보안 프로토콜인 SSL(secure sockets layer)가 제시되었으며, 현재는 TLS(transport layer security)라는 프로토콜이 인터넷 표준으로 인정받아 application 계층 아래로 메시지를 내리기 이전에 메시지를 암호화 후 전송하도록 하고 있다. 두 프로토콜은 유사한 점이 많아 흔히 SSL/TLS로 묶어 부르기도 한다.

- HTTP를 TLS을 사용해 암호화하는 프로토콜을 HTTPS라 하며, HTTPS 프로토콜을 지원하는 웹서버는 HTTPS 서비스를 위해 CA에 자신의 public key를 담은 인증서를 만들어야 한다.

- TCP로 통신을 하는 경우 사전에 3-way handshake를 통해 연결을 형성하듯, HTTPS로 통신을 하는 경우에도 사전에 SSL/TLS handshake를 통해 서로 메시지 전송 시 사용할 암호키를 교환하는 과정을 거친다. 그 과정은 다음과 같다.

1) TCP connection 구축 후 클라이언트가 서버에게 자신의 TLS 버전정보 등을 담은 메시지(client hello)를 전송한다.

2) 서버는 자신의 public key를 담고 있는 인증서를 클라이언트에 전송한다.

3) 클라이언트는 서버로부터 전송받은 인증서를 CA에 검증하여 서버의 public key를 얻는다.

  • 이를 위해 웹 브라우저는 신뢰할 수 있는 여러 CA의 목록과 각 CA의 public key 정보를 갖고 있다.

4) 문제 없을 시 클라이언트는 pre-master key를 서버의 public key로 암호화해 서버에 전송한다.

  • pre-master key: 무작위 바이트로 이루어진 값으로, 클라이언트와 서버가 같은 값을 공유한다. 서버와 클라이언트는 이 값을 통해 master key를 생성하고, 다시 이를 이용해 이후 통신에서 사용할 네 개의 키(Kc, Ks, Mc, Ms)를 생성한다.

    • 서버의 public key를 사용하는 게 아니라 이렇게 생성한 네 개의 키를 별도로 사용하는 이유는, 혹시나 발생할 지 모르는 보안 유출의 피해를 분산하기 위함이다.

  • Kc, Ks: 클라이언트/서버가 상대에게 메시지를 보낼 때 사용할 대칭키(세션키)

  • Mc, Ms: 클라이언트/서버가 상대에게 메시지를 보낼 때 사용할 MAC(해시값)을 만드는 데 사용할 키. 위에서 설명한 message integrity를 검사하기 위한 키값이다.

  • MAC(message authentication code): 일종의 해시값으로, Mc/Ms, 메시지 순서, 메시지의 종류, 메시지 내용을 해시함수로 연산한 값이다. 메시지 순서나 메시지 종류 같은 값은 TCP 헤더에 들어가는 값이지만, TCP/IP 구조상 TCP 헤더는 보안이 보장되지 않으므로 TLS에서 한번 더 이를 보장하기 위한 장치를 둔 것이다.

6. 방화벽

- 게이트웨이에 구현돼 있어, 게이트웨이를 오가는 패킷을 조사하여 내부 네트워크 정책에 반하는 패킷을 드랍하는 방식의 보안 기술이다. 패킷의 헤더를 보고 알 수 있는 정보만을 갖고(예를 들어, 현재 게이트웨이를 나가려는 패킷의 dest port num이 80인 패킷만 통과를 허용한다면 웹페이지 로드를 요청하는 패킷만 전송을 허용하는 것) 패킷 드랍 여부를 결정하는 방식(stateless packet filter)과, 패킷의 특성을 보고 그것이 그 프로토콜의 일반적인 규칙에 부합하는 패킷인지(예를 들어, 현재 게이트웨이를 나가려는 패킷이 TCP 패킷이라면 그 전에 TCP connection 구축이 있었는지) 등을 보고 패킷 드랍 여부를 결정하는 방식(stateful packe filter)이 있다.