Permutation Based Cryptography for IoT

(1)

Guido Bertoni¹ Joint work with

Joan Daemen¹, Michaël Peeters²and Gilles Van Assche¹

1STMicroelectronics²NXP Semiconductors

CIoT 2012, Antwerp, November 21

(2)

Permutation Based Cryptography for IoT Internet of Things Cryptographic Requirements

Motivation

Propose a cipher suite based on a single permutation and a public key primitive for the Internet of Things

(3)

Internet of Things Cryptographic Requirements

One possibility for Internet of Things is the adoption of the Datagram Transport Layer Security

Kind of adaptation of TLS for UDP

Other possibilities, but overall DTLS can be seen as a good example of crypto requirements

What we report here for DTLS can be easily adapted to other security protocols

(4)

(D)TLS cipher suite

One of the suggested cipher suite for DTLS and TLS is the ECCGCM[RFC5289]

ECC for DH key agreement and digital signature SHA2 for hash and HMAC for PRF

AES and GHASH for authenticated encryption

(5)

Simpliﬁcation

Three diﬀerent symmetric primitives

A luxury that low-end devices would love to avoid!

Use just one permutation for:

hashing

authenticated encryption

pseudo random number generation key derivation function

(6)

Permutation-based crypto: the sponge construction

Permutation-based construction: sponge

f: a b-bit permutation with b=r+c eﬃciency: processes r bits per call to f

security: provably resists generic attacks up to 2^c/2 Flexibility in trading rate r for capacity c or vice versa

(7)

Permutation Based Cryptography for IoT Security of the sponge construction

What can we say about sponge security

Generic security:

assuming f has been chosen randomly covers security against generic attacks

construction as sound as theoretically possible Security for a speciﬁc choice of f

security proof is infeasible Hermetic Sponge Strategy design with attacks in mind

security based on absence of attacks despite public scrutiny

(8)

Permutation Based Cryptography for IoT Applications

What can you do with a sponge function?

Regular hashing

Pre-sponge permutation-based hash functions

Truncated permutation as compression function: Snefru [Merkle ’90], FFT-Hash[Schnorr ’90], …MD6[Rivest et al. 2007]

Streaming-mode: Subterranean, Panama, RadioGatún, Grindahl[Knudsen, Rechberger, Thomsen, 2007], …

(9)

Message authentication codes

Pre-sponge (partially) permutation-based MAC function:

Pelican-MAC[Daemen, Rijmen 2005]

(10)

Stream encryption

Similar to block cipher modes:

Long keystream per IV: like OFB

Short keystream per IV: like counter mode

Independent permutation-based stream ciphers: Salsa and ChaCha[Bernstein 2007]

(11)

Mask generating function

(12)

Permutation Based Cryptography for IoT Authenticated encryption

Remember MAC generation

Authenticated encryption: MAC generation

(13)

Remember stream encryption

Authenticated encryption: encryption

(14)

And now together!

Authenticated encryption: just do them both?

(15)

Permutation Based Cryptography for IoT The duplex construction

Sister construction of sponge opening new applications

The duplex construction

Object: D=duplex[f, pad, r]

Requestingℓ-bit output Z=D.duplexing(_σ,ℓ) Generic security equivalent to that of sponge

(16)

The SpongeWrap mode

SpongeWrap authenticated encryption

Single-pass authenticated encryption Processes up to r bits per call to f

Functionally similar to (P)helix[Lucks, Muller, Schneier, Whiting, 2004]

(17)

The SpongeWrap mode

Key K, data header A and data body B of arbitrary length Conﬁdentiality assumes unicity of data header

Supports intermediate tags

(18)

The SpongeWrap mode

SpongeWrap, two simple operations:

D.initialize() D.duplexing(_σ,ℓ)

Frame bits for separating the diﬀerent stages[SAC 2011]

(19)

Permutation Based Cryptography for IoT Sponge functions: are they real?

Sponge functions exists!

Keccak Bertoni, Daemen, SHA-3 25, 50, 100, 200 Peeters, Van Assche 2008 400, 800, 1600 Quark Aumasson, Henzen, CHES 136, 176

Meier, Naya-Plasencia 2010 256, 384 Photon Guo, Peyrin, Crypto 100, 144, 196,

Poschmann 2011 256, 288

Spongent Bogdanov, Knezevic, CHES 88, 136, 176 Leander, Toz, Varici, 2011 248, 320 Verbauwhede

(20)

On the eﬃciency of permutation-based cryptography

The lightweight taste

Quark, Photon, Spongent: lightweight hash functions Lightweight is synonymous with low-area

Easy to see why. Let us target security strength 2^c/2 Davies-Meyer block cipher based hash(“narrow pipe”)

chaining value (block size): n≥^c

input block size (key length): typically k≥ⁿ feedforward (block size): n

total state≥^3c Sponge(“huge state”)

permutation width: c+r

r can be made arbitrarily small, e.g. 1 byte total state≥^c+8

(21)

On the eﬃciency of permutation-based cryptography

Permutations vs block ciphers

Unique block cipher features pre-computation of key schedule

storing expanded key costs memory

may be prohibitive in resource-constrained devices misuse resistance

issue: keystream re-use in stream encryption not required if nonces are aﬀordable or available

Unique permutation features diﬀusion across full state

ﬂexibility in choice of rate/capacity

(22)

Permutation Based Cryptography for IoT Boosting keyed permutation modes

Boosting keyed permutation modes

Taking a closer look at rate/capacity trade-oﬀ keyed generic security is c−a instead of c/2 with 2^aranging from data complexity down to 1 allows increasing the rate

Distinguishing vulnerability in keyed vs unkeyed modes in keyed modes attacker has less power

allows decreasing number of rounds in permutation

(23)

Numeric example

Say we have the following requirements:

we have a permutation with width 200 bits we want to realize diﬀerent functions desired security strength: 80 bits

we assume active adversary, limited to 2⁴⁸data complexity Collision-resistant hashing: c=2×⁸⁰⇒^r=40

SpongeWrap: c=80+48+1⇒^r=71 MAC computation: c=80⇒^r=120

(24)

Distinguishing vulnerability in keyed vs unkeyed modes

Unkeyed modes weaker than keyed modes?

MD5 hash function[Rivest 1992]

unkeyed: collisions usable in constructing fake certiﬁcates [Stevens et al. 2009]

keyed: very little progress in 1st pre-image generation Panama hash and stream cipher[Clapp, Daemen 1998]

unkeyed: instantaneous collisions[Daemen, Van Assche 2007]

keyed: stream cipher unbroken till this day

Keccak crypto contest with reduced-round challenges unkeyed: collision challenges up to 4 rounds broken[Dinur, Dunkelman, Shamir 2012]

keyed: 1st pre-image challenges up to 2 rounds broken [Morawiecki 2011]

(25)

Keccak-f: the permutations in Keccak

Operates on 3D state:

x y z

state

(5×⁵)-bitslices 2^ℓ-bitlanes param. 0≤ ℓ <⁷

Round function with 5 steps:

θ: mixing layer

ρ: inter-slice bit transposition π: intra-slice bit transposition χ: non-linear layer

ι: round constants

Lightweight, but high diﬀusion

#rounds: 12+2ℓfor b=2^ℓ25 12 rounds in Keccak-f[25] 24 rounds in Keccak-f[1600] High safety margin, even if unkeyed

(26)

Keccak: reference versions

Keccak with default parameters: Keccak[]

width b=1600: largest version rate r=1024:power of 2

gives generic security strength c/2=288 bits

roughly 7 % slower than the Keccak SHA-3 256-bit candidate For performance see eBash, Athena, XBX, etc.

Keccak[r=40, c=160]

width b=200: small state

c=160, generic security strength 80 bits gives rate of r=40

roughly 2.4 more work per input/output bit than Keccak[]

(27)

Reduced-round versions of Keccak: Keccup

For keyed modes use reduced-round versions of Keccak-f called Keccup[r, c, n]and Keccup-f[b, n]

we assume that the multiplicity 2^ais below 2⁶⁴ Keccup for IoT

state b=200 rate r=16

#rounds ... see next slides

(28)

Introducing dedicated variants

Sponge and duplex are generic constructions ﬂexible and multi-purpose

do not exploit mode-speciﬁc adversary limitations MAC computation

before squeezing adversary has no information about state relaxes requirements on f during absorbing

Authenticated encryption in presence of nonces nonce can be used to decorrelate computations Presented at[DIAC2012]

(29)

The monkeyDuplex construction

For authenticated encryption and keystream generation Initialization: key, nonce and strong permutation reduced number of rounds in duplex calls

(30)

Some monkeyDuplex Keccup varieties

n_init=12: dictated by chosen-input-diﬀerence attacks For b=200 we proposed n_duplex=1: streaming mode

b |^K| ^c ^r ⁿduplex n_init speedup

200 80 184 16 1 12 7.2

(31)

Consideration 1: monkeyDuplex and MAC generation

Reduced number of round could give a low propagation from last input block to ﬁrst squeezed block

Attack: change one (or few) bits in the last block of the ciphert text and adapt the MAC with high probability Considered for donkeySponge (MAC) overlooked for monkeyDuplex (AE)

(32)

Consideration 1: monkeyDuplex and MAC generation

The propagation of the duplex should be careful analysed Add a suﬃcient number of rounds before squeezing MAC Gives good diﬀusion and reduces the possibilities of the attacker

If the size of the MAC is larger than the rate, the nominal duplex round is applied after the ﬁrst block of MAC

(33)

Consideration 2: monkeyDuplex and Key + Nonce size

In the original proposal the size of (key + nonce)<b Depending on the size of b and protocol this might be too restrictive

Review of the initial phase of the scheme as well

(34)

Reviewing monkeyDuplex work in progress

Deﬁne three interfaces of the duplex object D.initialize(K)

D.crunching(_σ,ℓ): used to separate diﬀerent phases D.duplexing(_σ,ℓ): all other cases

The diﬀerence is the number of rounds of the Keccup-f

(35)

Permutation Based Cryptography for IoT Proposal for IoT

Practical proposals

Public key, like ECC P192 (why this? see next line..) Keccak[r=8, c=192] as hash function for digital signature Keccak[r=8, c=192] for PRF

rate can be increased to 40 bits if needed monkeyDuplex

D.initialize(K): Keccup[r=16, c=200, n=1]

D.crunching(σ,ℓ): Keccup[r=16, c=200, n=6]

D.duplexing(σ,ℓ): Keccup[r=16, c=200, n=1]

(36)

Performances

Two interesting papers will be presented at Cardis 2012:

Yalcin et al ”On the Implementation Aspects of Sponge-based Authenticated Encryption for Pervasive Devices”

Balasch et al ”Compact Implementation and Performance Evaluation of Hash Functions in ATtiny Devices” (presented yesterday by Tim)

(37)

Performances comparison in Software

What do you gain on ATtiny?

Algorithm RAM code size cycle (10³)

(500 byte message)

Keccak[] 244 868 716

Keccak[r=40, c=160] 48 752 1206

this proposal 48 752 180

AES v1 33 1659 140

AES Furios 192 1568 113

AES performances extrapolated from ECRYPT II web page (include multiple key schedules but no data integrity)

(38)

Performances comparison in Hardware

What do you gain in hardware?

Algorithm kGate cycle per byte

Keccak[] 10 5

Keccak[r=40, c=160] 6.5 3.6 this proposal 6.5 0.5

AES 2.4 8.6

[Keccak Implementation]130nm, area can be reduced increasing computational time

For AES only encryption no data integrity

(39)

Don’t forget, the Sponge can forget

If you are worried about ”midgame”[crypto 2012 rump session]

where a powerful attacker can read your entire intermediate state but not your keys you may want to use the forget or overwrite mode.

(40)

Conclusions and Future Work

Single permutation and a public key primitive satisfy all the cryptographic requirements of IoT

Performance point of view: the monkeyDuplex seems very attractive primitive

detailed analysis of the number of round per permutation is highly recomended

400 bit permutation for 128 bit security against collision resistance?

public key based on Sponge, we wish...

(41)

Permutation Based Cryptography for IoT That’s it, folks!

Questions?

Thanks for your attention!

Q?

More information on http://keccak.noekeon.org/

http://sponge.noekeon.org/