맨위로가기

CCM 모드

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

CCM 모드는 기밀성을 위한 카운터 모드와 인증을 위한 CBC-MAC을 결합한 인증 암호화 방식이다. 이 방식은 메시지에 CBC-MAC을 적용하여 메시지 인증 코드(MAC)를 생성한 후, 카운터 모드를 사용하여 메시지와 MAC을 암호화한다. CCM 모드는 러스 하슬리, 더그 와이팅, 닐스 퍼거슨에 의해 설계되었으며, CCM*과 같은 변형이 존재한다. CCM은 IEEE 802.11i, IPsec, TLS 1.2, 블루투스 로우 에너지 등 다양한 프로토콜에서 활용된다. OCB 모드의 특허 문제로 인해 CCM 모드가 IEEE 802.11i 표준의 필수 요소가 되었다.

더 읽어볼만한 페이지

  • 인증된 암호 방식 - 갈루와/카운터 모드
    갈루아/카운터 모드(GCM)는 유한체 산술을 이용해 인증 태그를 생성하는 블록 암호 운용 모드로, 카운터 모드 기반 암호화 방식과 유한체 연산을 결합하여 데이터 기밀성과 변조 방지를 제공하며 GHASH 함수로 인증 태그를 생성하고 하드웨어 가속이 가능하지만, 특정 환경에서 성능 저하나 보안 취약점 문제가 발생할 수 있다.
  • 블록 암호 운용 방식 - 초기화 벡터
    초기화 벡터는 블록 암호 운용 방식에서 암호문의 무작위성을 확보하고 동일 평문 블록 암호화로 인한 보안 취약점을 해결하기 위해 각 블록 암호화 단계에서 입력 데이터를 무작위화하는 데 사용되는 고유하고 예측 불가능한 값이다.
  • 블록 암호 운용 방식 - 갈루와/카운터 모드
    갈루아/카운터 모드(GCM)는 유한체 산술을 이용해 인증 태그를 생성하는 블록 암호 운용 모드로, 카운터 모드 기반 암호화 방식과 유한체 연산을 결합하여 데이터 기밀성과 변조 방지를 제공하며 GHASH 함수로 인증 태그를 생성하고 하드웨어 가속이 가능하지만, 특정 환경에서 성능 저하나 보안 취약점 문제가 발생할 수 있다.
CCM 모드
일반
약어CCM
유형인증 암호화 모드
암호화블록 암호
상세 정보
특징인증된 암호화
참조
주의 사항AES CCM은 암호화에 카운터 모드를 사용한다. 모든 스트림 암호와 마찬가지로, 동일한 키로 동일한 IV 값을 재사용하는 것은 치명적이다.

2. 암호화 및 인증

CCM 모드는 기밀성을 위한 카운터 (CTR) 모드와 인증을 위한 암호 블록 체이닝 메시지 인증 코드 (CBC-MAC)를 결합한 방식이다. CCM은 메시지에 대해 CBC-MAC을 계산하여 메시지 인증 코드 (MAC)를 얻고, 카운터 모드를 사용하여 메시지와 MAC을 암호화하는 "인증 후 암호화" 방식을 사용한다. 이때 암호화와 인증에 동일한 암호화 키를 사용할 수 있는데, 암호화에 사용된 카운터 값이 인증에 사용된 초기화 벡터와 충돌하지 않아야 한다.[4]

CCM 모드는 러스 하슬리, 더그 와이팅, 닐스 퍼거슨이 설계했으며, 개발 당시 러스 하슬리는 RSA 연구소에 근무했다.

CCM의 변형인 CCM*는 지그비 표준에서 사용된다. CCM*는 CCM의 모든 기능을 포함하며, MAC 길이를 0으로 선택하여 인증을 비활성화하고 암호화 전용으로 사용할 수 있다.[5]

2. 1. 작동 원리

CCM 모드는 기밀성을 위한 카운터 (CTR) 모드와 인증을 위한 암호 블록 체이닝 메시지 인증 코드 (CBC-MAC)를 결합한 방식이다. 이 두 가지 요소는 "인증 후 암호화" 방식으로 적용된다. 즉, 먼저 메시지에 대해 CBC-MAC을 계산하여 메시지 인증 코드 (MAC)를 얻은 다음, 카운터 모드를 사용하여 메시지와 MAC을 암호화한다. 암호화에 사용된 카운터 값이 인증에 사용된 (사전)초기화 벡터와 충돌하지 않는 한 동일한 암호화 키를 모두 사용할 수 있다.[4]

기본 블록 암호의 보안을 기반으로 이 조합에 대한 보안 증명[4]이 존재한다. 이 증명은 모든 블록 크기에 대한 CCM의 일반화와 모든 크기의 암호학적으로 강한 의사 난수 함수에도 적용된다 (카운터 모드와 CBC-MAC 모두에서 블록 암호는 한 방향으로만 사용되기 때문이다).[13]

2. 2. 보안성

CCM 모드는 기밀성을 위한 카운터 (CTR) 모드와 인증을 위한 암호 블록 체이닝 메시지 인증 코드 (CBC-MAC)를 결합한 방식이다. 이 두 가지 기본 요소는 "인증 후 암호화" 방식으로 적용된다. 즉, 먼저 메시지에 대해 CBC-MAC을 계산하여 메시지 인증 코드 (MAC)를 얻은 다음, 카운터 모드를 사용하여 메시지와 MAC을 암호화한다. 암호화에 사용된 카운터 값이 인증에 사용된 (사전)초기화 벡터와 충돌하지 않는 한 동일한 암호화 키를 모두 사용할 수 있다. 기본 블록 암호의 보안을 기반으로 이 조합에 대한 보안 증명[4]이 존재한다. 이 증명은 모든 블록 크기에 대한 CCM의 일반화와 모든 크기의 암호학적으로 강한 의사 난수 함수에도 적용된다 (카운터 모드와 CBC-MAC 모두에서 블록 암호는 한 방향으로만 사용되기 때문이다).

2. 3. CCM*

CCM*는 CCM 모드의 파생형으로, 지그비 표준에서 사용된다. CCM*는 CCM의 모든 기능을 포함하며, MAC 길이를 0으로 선택하여 인증을 비활성화하고 암호화 전용으로 사용할 수 있다.[5] CTR(Counter, 카운터) 모드와 CBC-MAC 모드를 결합한 CCM 모드는 암호화에는 CTR 모드를, 인증에는 CBC-MAC 모드를 사용한다. 암호화에 사용된 카운터 값이 인증에 사용되는 초기화 벡터와 충돌하지 않는 한, 동일한 키를 암호화와 인증 모두에 사용할 수 있다. 이러한 조합은 블록 암호의 안전성에 기반한 NIST의 안전성 증명이 존재한다.[12] 이 증명은 128비트 AES뿐만 아니라, 임의의 블록 길이의 블록 암호나 임의 길이의 의사 난수 함수[13]를 사용하는 일반화된 CCM 모드에도 적용된다.

CCM*는 ZigBee에서의 암호화에 이용되고 있으며, CCM 모드의 모든 기능을 가지고 있으면서 암호화에만 사용할 수도 있다.[14]

3. 성능

CCM은 메시지를 암호화하고 인증하기 위해 메시지 블록당 2회의 블록 암호화 연산을, 관련 데이터(암호화되지 않는 부분)의 인증을 위해 데이터 블록당 1회의 암호화 연산을 필요로 한다.[15]

Crypto++의 벤치마크에 따르면, 인텔 코어 2 프로세서(32비트 모드)를 사용했을 때, AES-CCM은 1바이트당 28.6 바이트당 사이클을 필요로 한다.[15]

CCM의 주목할 만한 비효율성은 다음과 같다:


  • CCM은 "온라인" 인증 암호가 아니며, 미리 메시지(및 관련 데이터)의 길이를 알고 있어야 한다.
  • 인증 코드(MAC) 생성 시, 관련 데이터의 길이는 가변 길이 인코딩이 이루어지며, 컴퓨터의 워드 길이보다 짧을 수 있다. 이는 (드물지만) 관련 데이터가 긴 경우 MAC 생성이 느려지는 원인이 될 수 있다.
  • 관련 데이터는 메시지 데이터 다음에 처리되므로, 관련 데이터가 고정되어 있더라도 미리 계산해 두는 것은 불가능하다.

3. 1. 효율성

CCM은 암호화 및 인증된 메시지의 각 블록에 대해 두 번의 블록 암호화 연산을 요구하며, 연관된 인증된 데이터의 각 블록에 대해서는 한 번의 암호화 연산을 요구한다.[6]

Crypto++ 벤치마크에 따르면, AES CCM은 32비트 모드에서 인텔 코어 2 프로세서에서 1바이트당 28.6 사이클이 필요하다.[6]

주목할 만한 비효율성은 다음과 같다.

  • CCM은 메시지(및 관련 데이터)의 길이를 미리 알아야 한다는 점에서 "온라인" 연관된 데이터(AEAD)를 사용한 인증 암호화가 아니다.
  • MAC 구성에서, 연관된 데이터의 길이는 가변 길이 인코딩을 가지며, 이는 기계 워드 크기보다 짧을 수 있다. 이는 연관된 데이터가 긴 경우(드물지만) 비관적인 MAC 성능을 야기할 수 있다.
  • 연관된 데이터는 메시지 데이터 후에 처리되므로, 정적 연관된 데이터에 대한 상태를 미리 계산하는 것이 불가능하다.

3. 2. 비효율성

CCM은 암호화 및 인증된 메시지의 각 블록에 대해 두 번의 블록 암호화 연산을 요구하며, 연관된 인증된 데이터의 각 블록에 대해 한 번의 암호화를 요구한다.[6]

Crypto++ 벤치마크에 따르면, AES CCM은 32비트 모드에서 인텔 코어 2 프로세서에서 28.6 바이트당 사이클이 필요하다.[6]

CCM 모드는 메시지를 암호화하고 인증하기 위해 메시지 블록당 2회의 블록 암호화 연산을, 관련 데이터(암호화되지 않는 부분)의 인증을 위해 데이터 블록당 1회의 암호화 연산을 필요로 한다.[15]

Crypto++의 벤치마크에 따르면, 인텔 코어 2 프로세서(32비트 모드)를 사용했을 때, AES-CCM은 1바이트당 28.6 사이클을 필요로 한다.[15]

주목할 만한 비효율성은 다음과 같다:

  • CCM은 메시지(및 관련 데이터)의 길이를 미리 알아야 한다는 점에서 "온라인" 연관된 데이터(AEAD)를 사용한 인증 암호화가 아니다.[6][15]
  • MAC 구성에서, 연관된 데이터의 길이는 가변 길이 인코딩을 가지며, 이는 기계 워드 크기보다 짧을 수 있다. 이는 연관된 데이터가 긴 경우 (드물지만) 비관적인 MAC 성능을 야기할 수 있다.[6][15]
  • 연관된 데이터는 메시지 데이터 후에 처리되므로, 정적 연관된 데이터에 대한 상태를 미리 계산하는 것이 불가능하다.[6][15]

4. 특허

CCM 모드 개발의 촉매는 오프셋 코드북(OCB) 모드의 IEEE 802.11i 표준 포함을 위한 제출이었다. OCB 모드 포함에 대한 반대가 있었는데, 이는 해당 알고리즘에 대한 특허 출원이 계류 중이었기 때문이다. 특허를 받은 알고리즘의 포함은 표준 구현자에게 상당한 라이선스 복잡성을 의미했다.[1]

OCB 모드의 포함은 이러한 지적 재산권 문제로 논쟁이 있었지만, 인증된 암호화 시스템이 제공하는 단순성이 바람직하다는 데 동의했다. 따라서 Housley 등은 특허에 얽매이지 않는 잠재적 대안으로 CCM 모드를 개발했다.[1]

CCM 모드가 OCB 모드보다 효율성이 떨어지더라도, 특허 라이선스 문제로 복잡해지는 것보다 특허가 없는 솔루션이 더 선호되었다. 따라서 CCM 모드는 IEEE 802.11i 표준의 필수 구성 요소가 되었고, OCB 모드는 선택적 구성 요소 상태로 격하된 후 결국 완전히 제거되었다.[1]

5. 이용

CCM 모드는 IEEE 802.11i(WPA2의 CCM 암호화 프로토콜인 CCMP로), IPsec,[7] TLS 1.2,[8] 블루투스 로우 에너지(블루투스 4.0)에서 사용된다.[9] TLS 1.3에서도 사용할 수 있지만, OpenSSL에서는 기본적으로 활성화되어 있지 않다.[10]

참조

[1] 간행물 Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality http://nvlpubs.nist.[...] 2004-05
[2] 간행물 Counter with CBC-MAC (CCM) IETF 2003-09
[3] 저널 rfc4309 http://tools.ietf.or[...] 2005-12
[4] 서적 Selected Areas in Cryptography 2003
[5] 서적 IEEE Standard for Local and metropolitan area networks--Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) https://www.corsi.un[...] IEEE Standards 2015-12-18
[6] 웹사이트 Crypto++ 5.6.0 Benchmarks http://www.cryptopp.[...] 2015-09-06
[7] IETF RFC Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)
[8] IETF RFC AES-CCM Cipher Suites for Transport Layer Security (TLS)
[9] 웹사이트 Bluetooth Low Energy Security https://www.bluetoot[...] 2017-04-20
[10] 웹사이트 Using TLS1.3 With OpenSSL https://openssl-libr[...] OpenSSL blog 2024-10-11
[11] 웹사이트 rfc4309 https://datatracker.[...] 2013-12-20
[12] 웹사이트 On the Security of CTR + CBC-MAC http://csrc.nist.gov[...] NIST 2013-12-20
[13] 문서 CTRモード、CBC-MACのいずれも，ブロック暗号の暗号化関数しか利用しないため、暗号化の逆演算（復号）ができる必要はない。
[14] 웹사이트 IEEE Standard for Local and metropolitan area networks--Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) http://standards.iee[...] IEEE Standards 2015-12-18
[15] 웹사이트 Crypto++ 5.6.0 Benchmarks http://www.cryptopp.[...] 2015-09-06
[16] IETF RFC Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)
[17] IETF RFC AES-CCM Cipher Suites for Transport Layer Security (TLS)
[18] 간행물 Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality http://nvlpubs.nist.[...] 2004-05
[19] 간행물 Counter with CBC-MAC (CCM) IETF 2003-09
[20] 저널 rfc4309 http://tools.ietf.or[...] 2005-12


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com