Download ProVerif User Manual. - Prosecco
Transcript
12 CHAPTER 3. USING PROVERIF Asymmetric encryption. For asymmetric cryptography, we consider the unary constructor pk, which takes an argument of type skey (private key) and returns a pkey (public key), to capture the notion of constructing a key pair. Decryption is captured in a similar manner to symmetric cryptography with a public/private key pair used in place of a symmetric key. 5 6 7 8 9 10 11 type s k e y . type pkey . fun pk ( s k e y ) : pkey . fun aenc ( b i t s t r i n g , pkey ) : b i t s t r i n g . reduc f o r a l l m: b i t s t r i n g , k : s k e y ; adec ( aenc (m, pk ( k ) ) , k ) = m. Digital signatures. In a similar manner to asymmetric encryption, digital signatures rely on a pair of signing keys of types sskey (private signing key) and spkey (public signing key). We will consider digital signatures with message recovery: 12 13 14 15 16 17 18 19 type s s k e y . type spkey . fun spk ( s s k e y ) : spkey . fun s i g n ( b i t s t r i n g , s s k e y ) : b i t s t r i n g . reduc f o r a l l m: b i t s t r i n g , k : s s k e y ; ge t m e s s ( s i g n (m, k ) ) = m. reduc f o r a l l m: b i t s t r i n g , k : s s k e y ; c h e c k s i g n ( s i g n (m, k ) , spk ( k ) ) = m. The constructors spk, for creating public keys, and sign, for constructing signatures, are standard. The destructors permit message recovery and signature verification. The destructor getmess allows the adversary to get the message m from the signature, even without having the key. The destructor checksign checks the signature, and returns m only when the signature is correct. Honest processes typically use only checksign. This model of signatures assumes that the signature is always accompanied with the message m. It is also possible to model signatures that do not reveal the message m, see Section 4.2.5. Tuples and typing. For convenience, ProVerif has built-in support for tupling. A tuple of length n > 1 is defined as (M1 , . . . , Mn ) where M1 , . . . , Mn are terms of any type. Once in possession of a tuple, the adversary has the ability to recover the ith element. The inverse is also true: if the adversary is in possession of terms M1 , . . . , Mn , then it can construct the tuple (M1 , . . . , Mn ). Tuples are always of type bitstring. Accordingly, constructors that take arguments of type bitstring may be applied to tuples. Note that the term (M ) is not a tuple and is equivalent to M . (Parentheses are needed to override the default precedence of infix operators.) It follows that (M ) and M have the same type and that tuples of arity one do not exist. 3.1.3 Process macros To facilitate development, protocols need not be encoded into a single main process (as we did in Section 2). Instead, sub-processes may be specified in the declarations using macros of the form l e t R(x1 : t1 , . . . , xn : tn ) = P . where R is the macro name, P is the sub-process being defined, and x1 , . . . , xn , of types t1 , . . . , tn respectively, are the free variables of P . The macro expansion R(M1 , . . . , Mn ) will then expand to P with M1 substituted for x1 , . . . , Mn substituted for xn . As an example, consider a variant docs/hello var.pv of docs/hello.pv (previously presented in Chapter 2): free c : channel . f r e e Cocks : b i t s t r i n g [ private ] . f r e e RSA : b i t s t r i n g [ private ] .