The Correctness of Crypto Transaction Sets

Abstract

This talk follows on more from the talks by Larry Paulson and Giampaolo Bella that we had earlier. The problem I'm going to discuss is, what's the next problem to tackle once we've done crypto protocols? We keep on saying that crypto-protocols appear to be "done" and then some new application comes along to give us more targets to work on -multi-media, escrow, you name it. But sooner or later, it seems reasonable to assume, crypto will be done. What's the next thing to do?The argument I'm going to make is that we now have to start looking at the interface between crypto and tamper-resistance.Why do people use tamper resistance? I'm more or less (although not quite) excluding the implementation of tamper resistance that simply has a server sitting in a vault. Although that's functionally equivalent to many more portable kinds of tamper resistance, and although it's the traditional kind of tamper resistance in banking, it's got some extra syntax which becomes most clear when we consider the Regulation of Investigatory Powers (RIP) Bill. When people armed with decryption notices are going to be able to descend on your staff, grab keys, and forbid your staff from telling you, then having these staff working in a Tempest vault doesn't give the necessary protection.

Integrity of intention (a theory of types for security APIs)

“…Intention represents the true and idealised aims of a designer when producing an API, which may be updated retrospectively. We define intention in the same way as it is used in Anderson's definition of an API attack [1], as "a malicious sequence of commands which result in an output the designer could not possibly have intended". A security policy document may be explicit or implicit, it may be wrong, it may have gaps.…”

“…With respect to key role, the API treats real world-people as resources, and decides whether or not a key (through assuming a particular role) should be granted access to a user. This reversal of perspective is of much more practical than focusing on roles of people, as the divisions there tend to be more straightforward 1 .…”

Type-based analysis of key management in PKCS#11 cryptographic devices

“…The attacks on PKCS#11 we consider in this paper are at the API level [2,4,5,6,10,11,13,21], i.e., the attacker is assumed to control the host on which the token is connected and to perform any sequence of (legal) API calls. The crucial functionalities of PKCS#11 are the ones for exporting and importing sensitive keys (CKA SENSITIVE), called C WrapKey and C UnwrapKey.…”

“…We have shown, however, that this is not always the case for commercial devices [6] (see, in particular, attack a4). 2 Our starting point is to allow variations in how the standard is implemented, in particular for what concerns assigning attributes to keys, and devise techniques to prove that these implementations achieve the desired security goals. Our approach is 'language-based' which makes it appealing for application to the firmware of real devices, as we discuss in Section 5.…”

Type-Based Analysis of PKCS#11 Key Management

“…The attacks on PKCS#11 we consider in this paper are at the API level [1,2,3,4,7,8,10,16], i.e., the attacker is assumed to control the host on which the token is connected and to perform any sequence of (legal) API calls. The crucial functionalities of PKCS#11 are the ones for exporting and importing sensitive keys, called C WrapKey and C UnwrapKey.…”