[보안] 대칭키 vs 비대칭키

프로토콜 통신 시 고려해야하는 것

• confidentiality (기밀성)
  • 메세지에 대한 내용을 서로만 알 수 있도록 하는 것
• integrity (무결성)
  • 메세지의 내용이 중간에 변조되지 않도록
• non-repudiation (부인 방지)
  • 메세지를 받았을 때 Bob이 딴소리 하지 않도록
• efficiency (효율성)
  • 너무 큰 메시지를 전달하지 않도록
• access and availability (가용성)
  • 서비스를 이용하고 싶은 시점에 이용할 수 있어야한다.
• authentication (인증)

Security Protocol(암호화 프로토콜)이란?

• Alice가 Bob에게 메세지를 보낸다고 가정했을 때
• 다음 3가지 암호화 프로토콜을 사용해 통신할 수 있다.
  • symmetric-key (대칭키)
  • asymmetric-key (비대칭키)
  • cryptographic hash (암호학적 해쉬함수)

symmetric-key (대칭키)

• Alice와 Bob이 동일한 대칭키를 공유해 메시지를 해독하는 방법이다.

  • m : 원본 데이터
  • Ks() : 대칭키
  • Ks(m) : 대칭키로 암호화 된 메시지
  • Ks(Ks(m)) = m : 대칭키로 복호화 된 메시지

• 대칭키 암호화/복호화 알고리즘은 비대칭키 암호화/복호화 알고리즘보다 빠르다. (효율성)

• 간단 예제를 통한 설명

  • 엘리스가 밥한테 1byte 짜리 Character를 전송한다고 가정해보자.
  • 이 1byte Character는 10110011(m) 과 같이 표현될 수 있다.
    • 보통의 Character들은 인코딩 되어 사용한다.
    • 가장 유명한 인코딩 방법은 아스키 Table이며,
    • 키보드 자판에 있는 Character, 숫자, 특수문자들을 0~127 사이의 정수에 매핑해 놓은 Table이다.
    • 결국, 전송하고자 하는 Character를 0~127 사이의 정수에 매핑한 뒤, 정수를 이진수로 변환해 전송한다는 것이다.
  • 그렇다면, 엘리스가 밥한테 어떤 Character를 전송하는지, 누가 훔쳐보더라도 모르도록 하고 싶다면 어떻게 전송해야할까? (기밀성)
  • 이를 위한 한 가지 아이디어가 바로 대칭키이다.
  • 앞으로 Character 하나를 주고 받을 때, 남들은 모르는 대칭키(비밀키)를 하나 공유하자고 약속한 것이다.

• 대칭키를 사용하는 순서는 다음과 같다.

  • 우선, 대칭키(비밀키)를 하나 정한다.
    • 예를들면 k = 01011001
  • 그다음, 엘리스가 밥한테 전송메시지(m)를 바로 보내는게 아니라,
  • 보내고자하는 전송메시지(m = 10110011)를 밥과 약속했던 비밀키(k = 01011001)로 XOR 계산해 암호화한다.
    • XOR : 동일한 비트의 위치를 보고 두개의 비트 값이 다르면 1 , 같으면 0 이다.
  • 전송메세지(m)를 대칭키(k)로 XOR 계산해, c = 11101010 라는 암호화 된 메세지가 만들어지면, 이를 전송한다.
  • 이러한 방법을 통해, 중간에 해커들은 암호화 된 메세지(c=11101010)를 가로챈다고 한들, 전송메세지(m=10110011)를 유추할 수 없게 된다.
    • 예를 들어, XOR 계산을 통해 암호화 된 메세지(c)의 첫 이진수가 0이라면, 전송메세지(m)의 이진수와 비밀키(k)의 이진수가 같다는 뜻이지만, 그 이진수가 0인지 1인지는 알 수 없다.
    • 또한, XOR 계산을 통해 암호화 된 메세지(c)의 첫 이진수가 1이라면, 전송메세지(m)의 이진수와 비밀키(k)의 이진수가 다르다는 뜻이지만, 어떤게 0이고 1인지 알 수 없다.
  • 하지만, 밥은 암호화 된 메세지(c)로부터 전송메세지(m)를 쉽게 복호화 할 수 있다.
    • 엘리스와 비밀키(k)를 공유하고 있기 때문이다.
  • 따라서, 밥은 암호화 된 메세지(c)를 비밀키(k)로 XOR 계산해 전송메세지(m)를 복호화한다.

• 대칭키의 첫번째 단점

  • 메세지(m)와 대칭키(k)의 비트 길이가 같아야한다.
    • 비트 간 XOR 계산을 해야하기 때문이다.
  • 하지만, 메세지의 크기는 엄청 커질 수 있기 때문에 현실적으로는 불가능하다.
  • 따라서, 주어진 메세지의 크기와 상관 없이 짧은 대칭키를 만드는 알고리즘을 만들었다.
    • 가장 유명한 대칭키 알고리즘은 AES이며,
    • 대칭키의 길이는 256비트이다.
    • K(m) → K(K(m)) 시에 256비트의 대칭키를 사용하며,
    • 메세지(m)의 길이와 상관 없이 빠르게 암호화가 가능하다.

• 대칭키의 두 번째 단점

  • 엘리스와 밥, 두 사람만 통신을 하고 있는데 캐롤과 데이브도 통신이 필요해졌다고 가정해보자.
  • 만약 캐롤과 데이브가 기존에 엘리스와 밥이 공유했던 대칭키(비밀키)를 사용하게 된다면,
  • 엘리스가 밥한테 전달하는 메시지를 케롤 또는 데이브가 복호화 가능하게 된다.
  • 이는 문제가 될 수 있다.
  • 따라서, 대칭키는 데이터를 전송하는 쌍마다 필요하다.
    • 즉, 통신을 총 n명이 한다면 nC2=n(n-1)/2 만큼의 대칭키 생성 작업이 필요하다.
  • 하지만, 이러한 대칭키들을 공유할 때 직접 만나서 전달할 수 없기 때문에
  • 대칭키 알고리즘은 빠르고 기밀성은 좋지만, 키 관리가 안좋다는 단점이 있다.
  • 그래서 나온 방법이 공개키 알고리즘이며, 또 다른 이름은 비대칭키 알고리즘이다.

asymmetric-key (비대칭키, 공개키)

• 위의 대칭키 암호화 알고리즘은, 통신 간에 동일한 키를 공유해 메시지를 암호화,복호화 하는 방법이었다.
• 하지만, 비대칭키 암호화 알고리즘은 동일한 키를 공유하는 것이 아니라, 각자 서로 다른 키를 만들어, 메세지를 암호화, 복호화한다.
  • 엘리스와 밥은 각자의 PC에서 공개키, 개인키 쌍을 생성한다.
  • 즉, 엘리스와 밥이 키를 협의해서 만들 필요가 없다는 것이다.
• 이것이 공개키 알고리즘이다.
• 각자가 만든 공개키는 전세계 사람들에게 공유하는 것이며, 개인키는 본인만 알고 있는 것이다.
  • 예를 들어, 메시지 m을 엘리스의 개인키로 암호화 했다면, 아래와 같이 표현한다.
    • KA-(m)
  • 암호화 된 메세지를 복호화 할 수 있는 방법은, 엘리스의 공개키로 복호화하는 방법 뿐이다.
    • KA+(KA-(m)) = m
  • 이처럼 공개키 알고리즘은, 어떤 한 키로 메세지를 암호화 한 후 대응하는 다른 키로 복구하는 것이다.
• 위 그림에서 개인키는 - , 공개키는 +로 표시 되어 있다.
• 개인키로 암호화하는 것을 서명이라고 부른다.
  • K-(m)
  • 본인만 생성 할 수 있기 때문이다.
• 또한, 메세지를 암호화 해 전송하고 싶다면, 메세지를 받는 사람의 공개키를 가져와 암호화해야, 메세지를 받는 사람이 본인의 개인키로 암호화 된 메세지를 풀 수 있다.
  • A가 B의 공개키로 메세지를 암호화 해 전송
    • KB+(m)
  • B는 본인의 개인키로 암호화 된 메세지를 복호화
    • KB-(KB+(m))
• 따라서, 메시지를 누군가한테 전송할 땐, 메세지를 열고자하는 사람의 공개키로 메시지를 암호화해서 보내주면 끝이다.
• 메세지를 받는 당사자가 개인키로 복호화하지 않고서는 아무도 해독하지 못한다.

cryptographic hash (암호학적 해쉬 함수)

• 공개키 알고리즘에는 단점이 있다.

  • 메세지의 크기가 크면 암호화 하는데 느리다는 것이다.
  • 따라서, 메시지의 크기를 줄이고자 나온 방법이 cryptographic hash 이다.
  • 메시지를 해쉬함수에 적용하면, 메세지의 크기에 상관 없이 해쉬 함수에서 정의해놓은 일정한 크기로 바뀌게 된다.
    • m → h(m)
  • SHA256 방법을 사용하면, 해쉬함수는 메세지를 256bits 크기로 줄여준다.

• cryptographic hash의 특징

  • 일방향성

    • cryptographic hash는 m이 주어졌을 때, h(m) 계산은 빠르지만,
    • h(m)으로 원본 메세지를 복구하는건 불가능하다.
    • 이것을 일방향성이라고 한다.

  • Collisionfree (충돌 방지)

    • 서로 다른 메세지 m과 n이 있을 때, H(m)과 H(n)이 동일한 m,n 쌍을 찾는 건 불가능하다.
    • 즉, 원본 메세지의 해쉬값과 다른 메세지의 해쉬값이 동일할 수 없다.
      • H(M)의 경우의 수는 2^256 이기 때문이다.
    • 따라서, 메시지가 조금만 바뀌어도 전혀 다른 해쉬값이 나오므로, 파일 변형을 확인할 수 있다.

  • 간단한 예제를 통한 설명

    • 메시지 m이 4기가 바이트 동영상이라고 가정하자.
    • 이 메시지는 크기가 너무 크기 때문에 암호화가 불가능하다.
    • 이 때, 원본 메시지(m)과 동일한 의미를 가지는 unique한 것에 대해 암호화 할 수 있다면, 원본 메세지(m)를 암호화 한 것과 같은 의미이지 않을까?
    • unique한 것을 h(m)이라고 한다면, m과 h(m)을 동일하게 볼 수 있다.
      • 어떤 누구도 메시지 m으로 부터 h(M)을 동일하게 만드는 것은 불가능하다.
      • m으로 부터 H(M)을 만드는 경우의 수는 2^256이기 때문이다.
    • 따라서, 메시지 m과 해쉬함수를 거친 h(m)을 동치로 취급해서 암호화하는 것이다.
      • k-(m) == k-(H(m))

Security Protocol(암호화 프로토콜)의 전체적인 흐름

• Alice와 Bob은 공개키, 대칭키, 암호학적 해시 함수를 공유하고 있으며, 상대방의 공개키를 알고 있다.

• Alice와 Bob이 기밀성, 무결성, 부인봉쇄를 만족하는 통신 프로토콜을 어떻게 구현할지 다뤄보자.

• Alice의 역할

  • 1) 대칭키(세션키) 생성 : Ks
    • Alice는 대칭키(세션키)를 생성한다.
  • 2) 공개키 다운로드 : KB+
    • Alice는 Bob의 공개키를 다운로드한다.
  • 3) 대칭키(세션키) 암호화 : KB+(Ks)
    • Alice는 Bob의 공개키를 사용해 대칭키를 암호화한다.
      • Bob만이 대칭키를 해독할 수 있게 만들기 위해
  • 4) 메시지 암호화 : Ks(m)
    • Alice는 대칭키를 사용해서 메시지를 암호화한다.
      • 대칭키는 Alice와 Bob만 알 수 있다.
        • Alice는 대칭키를 생성했기 때문에 알 수 있고
        • Bob은 대칭키를 해독할 수 있어 알 수 있다.
  • 5) 전자 서명 : KA-(H(m))
    • Alice는 원본 메시지에 해쉬함수를 적용한 H(m)을, Alice의 개인키로 서명해 전송한다.
      • 해쉬함수는 m을 크기와 상관 없이 작은 사이즈(H(m))로 만들어준다.
      • H(m)은 모든 사람이 볼 수 있다.
      • 모든 사람들은 Alice의 공개키를 볼 수 있기 때문이다.
    • 전자서명 하는 이유는?
      • Bob의 integrity(무결성), non-repudiation(부인방지)를 보장하기 위해서이다!
      • Bob은 해쉬함수 알고리즘을 알고 있기 때문에, 대칭키로 복호화 한 메세지 m 으로부터 H(m)을 생성할 수 있다.
        • Ks(Ks(m)) → m → h(m)
      • 또한, Bob은 Alice의 공개키를 알고 있기 때문에, Alice 공개키를 사용해 H(m)을 도출한다.
        • KA+(KA-(h(m)) = h(m)
      • 따라서, m으로부터 생성한 h(m)과 복호화 한 h(m)을 비교해, 같다면 메세지(m)이 같은 것으로 인식한다.
        • h(m)이 같다면, m이 다를순 없도록 해쉬 함수 알고리즘이 구성 되어있다.

• 즉, Alice는 대칭키 암호화, 메시지 암호화, 전자서명 3가지를 인터넷을 통해 Bob에게 전송한다.

  • 대칭키 암호화와 전자 서명의 사이즈는 작지만
  • 메시지 암호화의 사이즈는 크다.

• Bob의 역할

  • Bob이 메시지를 해독하는 과정도 중요하다.
  • 1) 대칭키 복원 : KB-(KB+(Ks)) = Ks
    • Bob의 공개키로 암호화된 대칭키(Ks)를 Bob의 개인키를 적용해 복원한다.
  • 2) 메세지 복원 후 해쉬함수 생성: Ks(Ks(m)) → m → h(m)
    • 복원한 대칭키(Ks)를 사용해서 암호화 된 메시지를 복원한다.
    • 이후, Bob은 해쉬함수 알고리즘을 알고 있기 때문에 m으로부터 h(m)을 생성한다.
  • 3) 전자서명 복원 : KA+(KA-(h(m)) → h(m)
    • Alice의 공개키를 사용해 Alice의 전자서명을 해독 한 뒤, h(m)을 뽑아낸다.
  • 4) Bob이 생성한 H(m)과 복원한 H(m)을 비교한다.
    • 같으면 Alice가 메세지를 보낸걸 부정할 수 없으므로, integrity(무결성), non-repudiation(부인방지) 충족 완료!
    • integrity
      • 메시지가 변하지 않았다라는걸 증명.
      • 메시지가 변경 됐다면 H(m) 값이 달라졌을 것이다.

• 문제점

  • 위에서 가정한 조건은 Alice와 Bob이 각자의 개인키와 공개키를 가지고 있고
  • Alice가 Bob에게 메세지를 전송한다고 했을 때, Bob이 자신의 공개키를 내려줬다고 가정한다.
  • 하지만 여기에는 허점이 존재한다.
  • Bob이 내려준 공개키가 정말 Bob의 공개키인지! 위조는 아닌지! Alice는 알 수가 없다.
    • 인터넷은 비대면이기 때문이다.
  • 그렇다면, 이 문제는 어떻게 해결할 수 있을까?
  • CA를 통해 해결한다.

CA (Certificate Authority)

• CA란 디지털 인증서를 제공하는 공인된 기업 (Certificate Authority 혹은 Root Certificate)이다.
  • 인증기관도 본인의 개인키와 공개키를 가지고 있다.
• Security Protocol(암호화 프로토콜)에서 Alice가 Bob에게 메세지를 전송할 땐, Bob의 공개키가 필요했다.
• 이 때, Bob은 Alice에게 공개키를 내려주기 전에, Bob의 공개키가 진짜 Bob의 공개키인지 CA를 통해 인증 받아야한다.
• 따라서, CA는 CA의 개인키로 Bob의 공개키를 서명한다.
• Alice는 CA를 통해 인증 받은 Bob의 공개키를, CA의 공개키를 사용해 복호화해 사용한다.
• 또한, 반대로 Bob이 Alice에게 메세지를 전송할 땐, CA를 통해 인증 받은 Alice의 공개키를 CA의 공개키를 사용해 복호화 한 뒤 사용한다.
• 하지만 이 때, 만약 Alice의 개인키가 도난 당해, CA의 개인키로 서명해준 Alice의 공개키가 유효하지 않게 됐다면
• Bob은 Alice로 부터 공개키 인증서를 받을때마다, 혹시 Alice의 공개키 인증서가 취소된 인증서가 아닌지 CA한테 물어봐야한다.
  • Alice가 본인의 개인키가 도난당한것을 알고 CA에게 공개키 인증서 폐지를 요청했다면
  • CA는 CRL이라는 인증서 취소 목록 데이터베이스에 인증서 고유 ID를 추가한다.
  • 만약 Bob이 CRL에 해당 공개키 인증서 폐지 됐냐고 물어봤을 때, 폐지 됐다면 Bob은 통신을 중단해야한다.
  • 하지만 Alice가 자신의 개인키가 해킹 당했다는것을 인지하지 못하여 인증기관에 신고를 하지 못한 경우라면 Bob은 피해를 받을 수 밖에 없는 구조이다.
  • 공개키 인증서를 받을 때마다 CRL 확인 요청을 해야하므로 상당한 비용이 발생한다.