CCM-läge
CCM-läge ( räknare med autentiseringskod för meddelanden med chifferblockkedje ; räknare med CBC-MAC ) är ett funktionssätt för kryptografiska blockchiffer . Det är en autentiserad krypteringsalgoritm utformad för att ge både autentisering och konfidentialitet . CCM-läge är endast definierat för blockchiffer med en blocklängd på 128 bitar.
Noce of CCM måste väljas noggrant för att aldrig användas mer än en gång för en given nyckel . Detta beror på att CCM är en härledning av räknare (CTR)-läge och det senare är faktiskt ett strömchiffer .
Kryptering och autentisering
Som namnet antyder kombinerar CCM-läget räknarläge (CTR) för konfidentialitet med autentiseringskod (CBC-MAC) för chifferblockkedjemeddelanden för autentisering. Dessa två primitiver appliceras på ett "autenticera-sedan-kryptera" sätt: CBC-MAC beräknas först på meddelandet för att erhålla en meddelandeautentiseringskod (MAC), sedan krypteras meddelandet och MAC med användning av räknarmod. Huvudinsikten är att samma krypteringsnyckel kan användas för båda, förutsatt att räknarvärdena som används i krypteringen inte kolliderar med (för-)initieringsvektorn som används i autentiseringen. Ett säkerhetsbevis finns för denna kombination, baserat på säkerheten för det underliggande blockchifferet. Beviset gäller också en generalisering av CCM för vilken blockstorlek som helst och för vilken storlek som helst av kryptografiskt stark pseudoslumpfunktion (eftersom i både räknarläge och CBC-MAC används blockchifferet bara i en riktning).
CCM-läget designades av Russ Housley, Doug Whiting och Niels Ferguson . När CCM-läget utvecklades var Russ Housley anställd av RSA Laboratories .
En mindre variant av CCM, kallad CCM*, används i Zigbee- standarden. CCM* inkluderar alla funktioner i CCM och erbjuder dessutom endast kryptering.
Prestanda
CCM kräver två blockkrypteringsoperationer för varje block av ett krypterat och autentiserat meddelande, och en kryptering på varje block av associerade autentiserade data.
Enligt Crypto++ -riktmärken kräver AES CCM 28,6 cykler per byte på en Intel Core 2-processor i 32-bitarsläge.
Anmärkningsvärda ineffektiviteter:
- CCM är inte en "on-line" autentiserad kryptering med tillhörande data (AEAD), eftersom längden på meddelandet (och tillhörande data) måste vara känd i förväg.
- I MAC-konstruktionen har längden på tillhörande data en kodning med variabel längd, som kan vara kortare än maskinordstorleken. Detta kan orsaka pessimistisk MAC-prestanda om associerad data är lång (vilket är ovanligt).
- Associerade data bearbetas efter meddelandedata, så det är inte möjligt att förberäkna tillståndet för statisk associerad data.
Patent
Katalysatorn för utvecklingen av CCM-läge var inlämnandet av offset-kodbok (OCB)-läge för inkludering i IEEE 802.11i -standarden. Motstånd framfördes mot införandet av OCB - läge på grund av en väntande patentansökan på algoritmen . Införandet av en patenterad algoritm innebar avsevärda licenskomplikationer för implementörer av standarden.
Även om införandet av OCB-läge ifrågasattes baserat på dessa immateriella rättigheter , kom man överens om att förenklingen som tillhandahålls av ett autentiserat krypteringssystem var önskvärt. Därför har Housley et al. utvecklat CCM-läge som ett potentiellt alternativ som inte var behäftat med patent.
Även om CCM-läge är mindre effektivt än OCB-läge, var en patentfri lösning att föredra framför en komplicerad av patentlicenser. Därför fortsatte CCM-läget att bli en obligatorisk komponent i IEEE 802.11i-standarden, och OCB-läget förpassades till valfri komponentstatus innan det så småningom togs bort helt.
Använda sig av
CCM-läge används i IEEE 802.11i (som CCMP , CCM-krypteringsprotokollet för WPA2 ), IPsec och TLS 1.2, samt Bluetooth Low Energy (från och med Bluetooth 4.0 ). Det är tillgängligt för TLS 1.3, men är inte aktiverat som standard i OpenSSL .