overview
basis
adoption
related
Guides:
Security &
InfoCrime
Governance
Information
Economy
Consumers
& Trust
e-Publishing
related
Profiles:
Forgery
& Fraud
Identity
Theft
|
basis
This page deals with the operation of digital signature
schemes.
It covers -
public and private keys
E-signature schemes typically centre on creation and verification
via public key cryptography,
with an algorithm using two discrete but mathematically
related keys -
- one
is used for generation of the digital signature or encryption
of a document/communication so that it is unintelligible.
- another
key is used for verification of the signature or decryption
of the data by/for the intended recipient.
Hardware
and software with two such keys forms an asymmetric cryptosystem,
with a private key (known only to the 'signer' and used
to generate the digital signature) and the public key.
The public key is often widely available as it is needed
for verification of the e-signature, typically through
publication to many people through an online repository.
In practice, although both keys are mathematically related,
if the system has been designed - and, as importantly,
implemented - securely it is not feasible to derive the
private key from knowledge of the public key.
As a result, in what is commonly characterised as the
principle of 'irreversibility', although many people may
know a given signer's public key (and rely on it for validating
that entity's signature) they cannot determine the private
key and use it to forge the e-signature.
the hash function
The hash function is used both for creation and verification
of an e-signature.
It is an algorithm that creates a digital 'fingerprint'
through a "hash value" of a standard length
which is usually much smaller than the message but nevertheless
substantially unique to it. Any change to the message
invariably produces a different hash result when the same
hash function is used.
In the case of a secure hash function (sometimes referred
to as a one-way hash function) it is "computationally
infeasible" to derive the original message from knowledge
of its hash value.
Hash functions therefore enable the software for creating
e-signatures to operate on smaller and predictable amounts
of data, while still providing robust evidentiary correlation
to the data in the original communication/document. They
serve as an efficient mechanism for assuring the integrity
of a document or communication, indicating that it has
not been tampered with since it was digitally signed.
generation and verification processes
Use of e-signatures involves two processes: creation and
verification.
Creation is performed by the signer. Verification is undertaken
by the recipient of the signature and/or another party,
including a forensic consultant or court.
Creation uses a hash result derived from
and unique to both the signed document/communication and
a specific private key. For that hash result to be secure
there must be only a negligible possibility that the same
digital signature could be created by combination of any
other message or private key.
Some e-signature schemes predicate creation on registration
of the signer, with a registration authority (RA) for
example determining the identity of an individual or organisation
seeking to participate in the particular scheme. The RA
might be a commercial vetting
service, credit reference
service, a government agency or data broker such as Choicepoint.
Participation is often dependent on the signer entering
into a contract with the scheme operator; such schemes
generally limit the operator's liability.
Verification is the process of checking
the digital signature by reference to the original item
and a given public key, thereby determining whether the
e-signature was generated for that document, communication
or transaction using the private key that corresponds
to the referenced public key.
As noted in the more detailed discussion
of authentication in the separate Security & InfoCrime
guide elsewhere on this site, that verification may
- form
one element of broader personal identification and authorisation
schemes (eg this person has the valid signature but
lacks the requisite authorisation for a particular transaction)
-
be accompanied by biometric identifiers, smart
cards and other identification technologies
What
is involved in signing?
To sign a document or communication (eg an email message)
or authorise a transaction such as a payment or release
of health records the
signer first delimits the boundaries of what is to be
signed. A hash function in the signer's e-signature software
(held on a personal computer or other device
that is assumed to be protected from unauthorised access)
automatically computes a hash result that in practice
is unique and specific to the message. The hash is entirely
independent of the user's handwritten signature and is
not, for example, a digital image derived from a scan
of an ink on paper signature.
The software then transforms the hash result into an e-signature
using the signer's private key. It is expected that the
resultant signature will be unique both to the document/communication
or transaction and to the private key used to create it.
Typically, an e-signature (a digitally signed hash result
of the message) is attached to the particular signed data
and transmitted as part of that document/communication
or transaction. It may, however, be transmitted as a separate
data element or stored separately, subject to preservation
of a reliable association with the particular document,
message or authorisation. Given that a digital signature
is unique to the signed data, it is useless if wholly
disassociated from that document/communication.
Verification of a digital signature is accomplished by
computing a new hash result of the original message by
means of the same hash function used to create the signature.
Using the public key and the new hash result, the verifier
checks whether the e-signature was generated through use
of the corresponding private key and whether the newly
computed hash result matches the original hash result
(ie the hash that was transformed into the e-signature
during the signing process).
Confirmation of the e-signature by that verification software
is dependent on two factors.
The signer's private key must have been used to digitally
sign the message, assumed to be the case if the signer's
public key was used to verify the signature - the signer's
public key will verify only a digital signature generated
with the signer's private key.
The integrity of the document/communication must also
be intact. That is signified if the hash result computed
by the verifier is identical to the hash result extracted
from the e-signature during the verification process.
Various asymmetric cryptosystems create and verify digital
signatures using different algorithms and procedures,
but share this overall operational pattern.
association
To verify a digital signature, the verifier must have
access to the signer's public key and have assurance that
it corresponds to the signer's private key. However, a
public and private key pair has no intrinsic association
with any person; it is simply a pair of numbers. It is
therefore necessary to reliably and easily associate a
particular person or entity to the key pair. That association
is integral to the use of e-signatures.
In relationships involving only a few parties (particularly
where there are recurrent transactions), each party can
simply communicate the public key by a secure mechanism
such as face to face contact or a courier.
That mechanism for associating the keys is not viable
for much activity on the net, distinguished by -
- a
large number of transactions (including one-off and
recurrent interactions that may be minutes or months
apart)
- parties
that are geographically distant from each other
- dealings
between individuals, government agencies, SMEs and major
corporations or their agents (eg payment processors
and fulfilment specialists)
- concerns
about trust, reliability and repudiation
- concerns
about speed of verification and reduction of transaction
costs
Signers have accordingly adopted two approaches.
One approach, favoured by some members of the ICT community,
has been to self-publish their public keys - typically
with a statement such as "signatures verifiable by
the following public key are mine".
That approach has not had mass acceptance, given that
reliance upon an essentially self-referential statement
involves risks of
- trusting
a phantom (does the individual or organisation really
exist)
- being
the victim of personal or corporate identity theft
- attempting
to disprove a false denial of a digital signature if
a transaction should turn out to prove disadvantageous
for the purported signer.
A common response to that problem is use of one or more
trusted third parties (TTP) to associate an identified
signer with a specific public key.
certification authorities
That trusted third party - which generally operates on
a commercial basis, is often independent of government
and may operate across national boundaries - is commonly
characterised as a certification authority (CA).
To associate a key pair with a prospective signer, the
CA typically issues a certificate - an electronic record
that lists a public key as the 'subject' of the certificate
and confirms that the prospective signer (aka the subscriber)
identified in the certificate holds the corresponding
private key.
A certificate serves to bind a key pair with a particular
subscriber. A "recipient" of the certificate
desiring to rely upon a digital signature created by the
subscriber named in the certificate (whereupon the recipient
becomes a "relying party") can use the public
key listed in the certificate to verify that the digital
signature was created with the corresponding private key.
If such verification is successful, it offers some assurance
that the corresponding private key is held by the subscriber
identified in the certificate and that the e-signature
was created by the particular subscriber.
The CA digitally signs the certificate to ensure its authenticity,
with that signature being verified through the CA's public
key listed in another certificate by another CA. That
other certificate can in turn be authenticated by the
public key listed in a further certificate. The issuing
CA must digitally sign its own certificate during the
operational period of the other certificate used to verify
the CA's digital signature.
To make a public key and its identification with a specific
subscriber readily available for use in verification,
the certificate may be published in a repository or made
available by other means.
Repositories are online databases of certificates and
other information available for retrieval and use in verifying
e-signatures. That retrieval can be undertaken automatically
by having the verification program interact with the repository
to obtain certificates as needed.
timeframes
An ink on paper signature lasts until the ink fades, paper
decays or characters are erased. E-signatures, in contrast,
are generally expected to have a finite life, rather than
being current and valid for all time.
As a result e-signatures generated by a subscriber to
authenticate a document and by a CA to validate its certificate
are usually time-stamped (in some instances by TTP timestamp
providers) to assist verification of whether the digital
signature was created during the 'operational period'
identified in the certificate.
reliability and liability
Once issued, a certificate may prove to be unreliable.
That may be because the subscriber loses control of the
private key after issue or one or more TTPs are compromised,
eg through inappropriate release of information by staff
or a hacker.
As with passports and
other official documents, it is conceivable that a subscriber
might gain a certificate by supplying false information
to the CA at the time of issue (eg misrepresenting
personal identity).
When alerted to unreliability the certification authority
should then
- revoke
(permanently invalidate) the certificate
- suspend
(temporarily invalidate) the certificate
with or without the subscriber's request, depending on
the circumstances.
Most e-signature regimes accordingly envisage that immediately
after revoking/suspending a certificate - with information
being added to a Certificate Revocation List (CRL) or
Suspension List (CSL) - the CA will
- publish
notice of that revocation or suspension
-
notify entities who inquire or who are known to have
received an e-signature verifiable by reference to the
unreliable certificate
- advise
entities who inquire about the status of the e-signature.
Public Key Infrastructure (PKI)
As the following page of this note suggests, much discussion
regarding e-signatures has been conceptualised as disagreement
about public key infrastructure or merely the ambitions
of bodies such as Australia's Government Public Key Agency
(GPKA)
and 1998 Gatekeeper report.
Like digital signatures and e-signatures the concept in
practice means different things to different people. It
can most profitably be characterised as a set of relationships
and assumptions rather than a physical entity. PKI involves
the interaction of document signers and recipients, government
regulatory agencies, standard setting and auditing bodies,
entities involved in issuing and verifying certificates
(including agents such as ISPs, accountants and law firms),
courts and mediation bodies, and IT or other service providers.
PKI regimes thus encompass -
-
national, international and nongovernment legal frameworks
and industry codes
- identification
and maintenance of global best practice standards for
internet interactions
-
a transparent and appropriate balance of risks and liabilities
among all participants in the scheme
- effective
quality control protocols and practices, including maintenance
of security and respect for fiduciary duties
- delivery
of services on a commercial or non-commercial basis,
within and across jurisdictions
- promotion
of the scheme, since in practice it is not cost effective
if (as in Australia) it is perceived as costly or inappropriate
and is therefore adopted by only a handful of participants.
next page
(adoption)
|
|
Ketupa