As devices proliferate and become more mobile, managing relationships between them will be critical. Devices will move in and out of range of each other and can interact using wireless protocols and peer-to-peer connections, taking advantage of temporary or semi-permanent secure connections to share information and access services.

Using digital certificates is considered the best-known method of establishing identity in network communications. A certificate provides a binding between identity information and a public key; a key pair can subsequently be used for key exchange to set up secured communications and for digital signatures, to validate transactions.

However, digital certificates can represent a substantial investment, both in infrastructure (to protect the keys used), memory (to store and manipulate the certificate), and bandwidth (in repeatedly transferring the certificate to various entities). Implicit certificates, known in the cryptographic community but not widely used, are smaller and faster than those in common use. Implicit or “bullet certificates” can enable a low-resource trust model for resource-constrained settings, ad-hoc networks and applications requiring printed certificates. They can also enable applications in these special situations that will not work using conventional certificates.

Consider the following applications which are well-suited to implicit certificates:

As the public-key scheme in ad-hoc sensor networks, which may have frequent new entrants and continually changing trust relationships. Implicit certificates provide a lightweight certificate scheme for use in these constrained environments.

As “optimal mail certificates” or postage stamps. For example, the small two-dimensional machine-readable postage marks in use today could use a form of implicit certificate. This could also apply to any situation in which a very small certificate is required.

As a trust scheme for peripheral devices: if a borrowed USB drive is connected to a secured PC, the PC may use a security scheme which quickly certifies the drive for temporary use. In this scenario, enrolment generates an implicit certificate between the PC and the connected device.

In any situation where certificates are generally used and a lightweight certificate is preferable: e-mail systems, logical and physical access, secure online transactions; and for transactions using mobile devices. In these situations, the benefits of using an implicit certificate scheme are simple: Smaller certificates, lower bandwidth usage, optimized processing.

What is an Implicit Certificate?

As with conventional or “explicit” certificates, implicit certificates are made up of three parts: identification data, a public key and a digital signature which binds the public key to the user’s ID data and verifies that this binding is accepted by an authority (or trusted-third-party).

Within a conventional certificate, the public key and digital signature are distinct data elements. In contrast, the public key and digital signature are ‘super imposed’ in implicit certificates and allow the recipient to extract and verify the public key of the other party from the signature portion. This substantially reduces the bandwidth required as there is no need to transmit both the certificate and the verification key.

Advantage #1: Smaller

Explicit certificates are relatively large. An ECDSA-signed certificate, at an 112-bit security-strength, requires 680 bits plus the user’s ID data (which is taken to be the same size in all cases). Using RSA keys at the same strength, the certificate is 4096 bits plus the ID data. A comparable implicit certificate is only 232 bits plus the ID data.

Table 2 shows certificate sizes at a few security strengths. 

Advantage #2: Faster

Implicit certificates are faster than explicit certificates because deriving the public key is faster than verifying a digital signature (which is necessary in an explicit certificate). In addition, some calculations can be combined during protocol operations. There is no explicit check of the signature in using an implicit certificate; all verification is performed as part of the use of the certificate.

Table 3 provides a comparison of the operational costs of a conventional certificate versus an implicit certificate.

Using an ordinary X.509 certificate, evidence of the binding between an entity and its public key is obtained during processing. Using an implicit certificate, evidence that the given (extracted) public key is genuinely bound to this entity is only corroborated by subsequent use of the corresponding private key (for example, completion of an authenticated key agreement scheme or a signing operation).

It is important to note that with an implicit certificate scheme, steps 1, 2 and 3 above can be combined during protocol operation, resulting in fewer operations than shown in the table. For example, executing the MQV protocol (described in Code & Cipher vol. 1, no. 2), when used with implicit certificates, requires only one computation involving elliptic curve points, during MQV computation; steps 1 and 2 are folded into step 3.