Implicit Certificates

Implicit Certificates are a variant of public key certificate, such that a public key can be reconstructed from any implicit certificate, and is said then to be "implicitly" verified, in the sense that the only party who can know the associated private key is the party identified in the implicit certificate. This does not rule out the possibility that nobody knows the private key, but this possibility is not considered a major problem.

By comparison, traditional public-key certificates include a copy of the public key and the digital signature of the certification authority. Upon verification of the digital signature, the public key is "explicitly" verified, in the sense that the party identified in the certificate knows the associated private key and is the only party who can know the private key. Unlike an implicit certificate, there is no possibility that nobody knows the private key. For the purposes of this article, such certificates will be called "explicit" certificates.

Elliptic Curve Qu-Vanstone (ECQV) are one kind of implicit certificates. This article will use ECQV as a concrete example to illustrate implicit certificates.

The cryptographic portion of an ECQV implicit certificate is the size of an elliptic curve point, making it considerable smaller than a comparable explicit certificate. Smaller certificates are useful in highly constrained environments, such as Radio-frequency Identification RFID tags, where not a lot of memory or bandwidth is available.

Digital certificates are 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 authenticate users or transactions for example.

Conventional explicit 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 identification data (ID). The digital certificate is created by a trusted third party and its signature can be independently verified by anyone in the network. The public key, ID and digital signature are distinct data elements which make the up the physical size of the certificate. Conventional certificates can get very large. For example, a standard X.509 certificate is on the order of 1KB in size (~8000 bits).

Implicit certificates carry the same data (ID, public key and digital signature) but the data elements are super imposed into a string the size of the public key. For example using an elliptic curve system at 160 bits would give us implicit certificates of size 160 bits.

With implicit certificates there is no explicit validation of the Certificate Authority's (CA’s) signature on a certificate. Instead, a user computes a public key from the implicit certificate and simply uses it in the intended ECC operation e.g. key agreement protocols such as ECDH and ECMQV, or signing such as ECDSA. The operation will fail if the certificate is invalid. Thus ECQV is regarded as an implicit validation scheme. Computing the public key is very fast, much faster than a public key operation.

Generating Implicit Certificates

Initially the elliptic curve parameters must be agreed upon. We define $G\; ,$ as a generating point of order $n\; ,$. The Certificate Authority (CA) will have private key $c\; ,$ and public key $Q\_\{CA\}\; =\; cG\; ,$. Alice will be the user who requests the implicit certificate from the CA.

# Alice generates a random integer $a\; ,$ and computes $aG\; ,$ and sends that to the CA. The CA does all the rest.
# CA Select a random integer $k\; ,$ from $[1,\; n-1]\; ,$ and computes $kG\; ,$.
# CA computes $gamma\; =\; aG\; +\; kG\; ,$ (this is the implicit certificate)
# CA computes $e\; =\; extrm\{H\}(gamma\; parallel\; extrm\{ID\}\_A)\; ,$, where $extrm\{H\}\; ,$ is a cryptographic hash function, such as SHA and $extrm\{ID\}\_A\; ,$ is Alice's identifying information.
# CA computes $s\; =\; ek\; +\; c\; pmod\{n\}\; ,$
# CA sends $(s,\; gamma)\; ,$ to Alice

Alice’s private key is $alpha\; =\; ea\; +\; s\; pmod\{n\}\; ,$

Alice’s public key is $Q\_A\; =\; egamma\; +\; Q\_\{CA\}\; ,$

Computing the Public Key from the Implicit Certificate

Computing Alice's public key $Q\_A\; ,$ can be computed by any third party provided they know $gamma\; ,$, $extrm\{ID\}\_A\; ,$ and $Q\_\{CA\}\; ,$.

Note that the size of the implicit certificate $gamma\; ,$ is the same size as Alice's public key $Q\_\{CA\}\; ,$.

ecurity

A security proof for ECQV has been published.

References

* Darrel Hankerson, Alfred Menezes and Scott Vanstone, "Guide to Elliptic Curve Cryptography, Springer", Springer, 2004.
* Certicom Research, [http://www.secg.org/?action=secg,docs_draft] "Standards for efficient cryptography, SEC 4: Elliptic Curve Cryptography", Draft document , November 11, 2006.
* Certicom.com, [http://www.certicom.com/index.php?action=res,cc&issue=2-2&&article=3] "Explaining Implicit Certificates", Code and Cipher Vol. 2, no. 2
* Leon Pintsov and Scott Vanstone, "Postal Revenue Collection in the Digital Age", Financial Cryptography 2000, Lecture Notes in Computer Science 1962, pp. 105-120, Springer, February 2000.
* Daniel R. L. Brown, Robert P. Gallant and Scott A. Vanstone, "Provably Secure Implicit Certificate Schemes", Financial Cryptography 2001, Lecture Notes in Computer Science 2339, pp. 156-165, Springer, February 2001. [http://www.cacr.math.uwaterloo.ca/techreports/2000/corr2000-55.ps Preprint (postscript)]

ee also

* Elliptic curve cryptography