Privacy Law and Policy Reporter
Public key infrastructures (or PKIs) are an emerging option for establishing identities and/or credentials in electronic commerce. A PKI describes a set of trusted third parties that vet individuals or entities and issue them with digital certificates, and the rules governing the conduct of those third parties. One example of a PKI model is the suggested Australian public key authentication framework (PKAF).
Any authentication scheme raises privacy concerns. PKI, with its connotations of centralisation and third party controls, arouses additional fears. Many concerns stem from misconceptions over how a PKI should work. This paper will try to show that the Australian PKAF model is in fact decentralised, based on a set of uniform standards over the third parties. A number of privacy positive properties flow on from this fact, including isolation of personal information, minimisation of data gathering, and provision for pseudonymity.
In the online world, the first question has always been ‘how do I know who I’m dealing with?’ The root problem is of course separation — you have no direct means of telling who is really at the end of the line. You don’t even have the sound of someone’s voice to go by; indeed, we can expect to be dealing with machines as electronic commerce becomes increasingly automated. Moreover, in online business you may need to know what role your correspondent has, rather than who they really are. So authentication needs to encompass the ability to prove your business relationships, authorisations, membership(s), delegations and so on, as well as — or instead of! — your personal identity.
In authentication debates, much is made of the ‘aggregation of trust’ in traditional business dealings. For example, you tend to build up relationships over time with retailers or suppliers, where familiarity, experience and physical presence all add to the confidence and security of your transactions. Aggregation of trust is of course next to impossible in the electronic environment.
Electronic authentication, especially the use of public key schemes, is often based on a ‘delegation’ of trust in place of aggregation. This strikes some people at first as abnormal, yet delegated trust is well worn in many types of business, especially where people act as officers of organisations or members of special recognisable groups.
Medical doctors are a good example. A doctor is authorised to write drug prescriptions and a pharmacist will usually fulfil a prescription without personally knowing the doctor who wrote it (after all, we would expect the doctor’s signature to be illegible!). The pharmacist’s ability to ‘trust’ the prescription is based on there being systems for only issuing prescription forms to registered doctors. So the pharmacist actually ‘trusts’ some parent body rather than the doctor directly.
Note too that the ‘trust’ in the doctor-pharmacist example is very specific. Notwithstanding that professional pharmacists have something of a watchdog role, looking out for inappropriate drugs and interactions, in prescription transactions they are not required to trust the doctor’s medical judgement or conduct. All the pharmacist really ‘trusts’ is that the doctor has authority to write the prescription. ‘Trust’ is perhaps the most overloaded term in electronic commerce.
Public key authentication uses ‘asymmetric cryptography’ to create essentially unique digital signatures. Each participant in a public key system has at least one pair of keys. The keys are very long numbers, held on disk or in smartcards, and used automatically in the system software. Asymmetric key pairs have a special property where a file that is encrypted by one of the keys may only be decrypted by the other. Furthermore, while the keys are mathematically related to one another, it is not possible to deduce the value of one key from the other.
One key in each pair must be kept private by the user while the other key is made public. To create a digital signature for a given document, the user in effect encrypts the document using the private key. Anyone possessing a copy of the matching public key can therefore decrypt the document. Successful decryption reliably indicates that the document was ‘signed’ by the holder of the private key, and if you can trust that you know who that is, then authentication follows.
An added benefit of digital signatures is integrity. Because the signature is calculated using the document itself, it is essentially unique to that document. Any changes to its contents will be revealed when the signature is decrypted. Note that a digital signature, while based on cryptographic methods, does not in itself provide confidentiality. If a document needs to be kept secret in transit or in storage, it can be separately encrypted after it has been digitally signed.
A variety of authenticators are available in electronic commerce, including passwords, static PINs, random PIN generators and public-private key pairs. A number of biometric technologies are also entering the market, including fingerprint scans, voice prints, retina scans and ‘signature dynamics’. Authentication applications range from logical access control (for networked systems like computers and internet bank accounts) and physical access control (such as building entry) through to document authentication, involving some electronic signature that binds a person to a particular file. Most biometrics are used for access control, with the notable exception of signature dynamics, which shows some promise for document authentication. But without doubt the most mature and best supported approach is public key.
A certification authority (CA) is a trusted agent that binds a person or entity to a key pair. A digital certificate is a tamper-resistant document issued by a CA, containing the key owner’s name and a copy of their public key. The CA signs the certificate with their own digital signature.
Different standards of identification may apply to the recipients of different certificates, and higher ‘value’ certificates obviously merit more stringent identification protocols. For personal certificates, this commonly means the presentation of high grade identification documents, but for special purpose business certificates, identification may be implicit in existing, pre-certification processes. A doctor, for instance, may not have to present her passport and driver’s licence in order to obtain a certificate if her medical registration board was to act directly as a CA, since she will have already been identified at the appropriate level.
In 1996, Standards Australia published a detailed discussion paper on the form and function of an Australian national public key authentication framework (PKAF). The paper defined the roles of different levels of CA, from organisational CA (OCA) at the lower levels, through ‘intermediate CA’ (ICA, equivalent to PCA), up to a root CA at the top of the hierarchy. OCAs may delegate registration responsibility to organisational registration authorities (ORAs) — see Figure 1 below.
Misconceptions abound as to some of the key properties of the PKAF structure. We will look at these before moving on to address privacy.
PKAF is often thought of as some sort of network where the links between CAs are imagined to carry information relating to the issuance of certificates. In fact, the links denote approvals (that is, certifications) rather than online communications.
When a CA issues a certificate, it has no need to refer to any higher ICA, much less the root CA. The CA’s own certificate, issued by an ICA, authorises the CA to issue and sign certificates according to its certificate policy.
The PKAF tree gives the impression of centralisation, yet the only thing that is centralised is control over policy compliance. The details of the policies themselves, especially the rules for membership of each CA, are left for the CAs to decide.
For each certificate to be fit for its intended purpose, it is essential to have confidence in the ability of CAs to implement their respective certificate policies. In PKAF, such confidence comes from third parties, the ICAs. And confidence in the ICAs in turn can come from a fourth party, the peak body. The third and fourth parties have no interest in the individuals out at the ends of the PKAF tree.
The relationship between OCAs and an ICA might best be modelled on the relationship between ISO 9000 compliant organisations and their quality certification body. An ISO 9000 certification is based on a quality assurance plan that is specific to the organisation. ISO 9000 certifiers get their imprimatur from a fourth party, the national standards accreditation body (akin to a root CA). Certification in general is optional, it comes at an acknowledged cost, to be financed by the organisation, and it confers no special legal protection except that it evidences good practice. These properties are common with PKAF.
It is sometimes thought that public key infrastructure is at odds with autonomous cyber communities. But in fact, under PKAF these communities are free to define and control themselves via locally controlled OCAs. This is due to the ability to write separate certificate policies for each OCA, dedicated to the purpose of the respective certificates.
Consider those bodies which today control registration of certain practising professionals. For instance, a law society and a medical registration board might both establish OCAs in order to issue digital certificates to their members. If the processes for issuing those certificates are integrated with present registration practices, then the certificates could represent electronic credentials. Thus, a title search digitally signed by a lawyer could be relied upon by a home buyer if the lawyer’s certificate came from a recognised law society. And likewise, an electronic prescription digitally signed by a doctor could be trusted by a pharmacist if the doctor’s certificate came from the recognised registration board. The relying parties in these respective transactions may care little for the actual identities of the signatories; rather, the relying parties need to trust the validity of the credentials.
To date we have tended to think of digital certificates as being like electronic passports. Commercial CAs typically grade their certificate offerings according to the degree of identification required of the applicant, and the Commonwealth’s Project Gatekeeper has almost enshrined the concept of ‘50 point’, ‘100 point’ and ‘150 point’ certificates. But this is unfortunate because it is more accurate and far more powerful to think of certificates as electronic credentials, specific to the CA’s community of interest.
In the real world, we don’t characterise credentials according to personal identity levels. Rather, we allow different communities or bodies to set their own rules for admission. The legitimacy of those rules (which is the same thing as the authority to issue credentials to, say, lawyers and doctors) may be established in a number of ways. Certain bodies can be given their authority by legislation or regulation. Ongoing authority may be subject to quality controls, such as the accreditation of universities to confer degrees in given areas. And of course general confidence in these types of authority systems tends be built up over time.
So it is important to note that certificates issued under PKAF by different OCAs are not all equivalent. The certificates issued to doctors and to lawyers in the previous example would all be ‘PKAF compliant’, trusted for their intended purposes, yet clearly they would not be equivalent in any way.
With respect to centralisation, we have seen how PKAF supports independent communities of interest. The PKAF structure possesses several related properties that are very good for privacy, as follows.
As discussed, PKAF is not an online network of CAs. No data flows between an OCA and its PCA or PAA in the course of registering and certifying end users. Thus there is no aggregation of personal data (or even public data) at higher level authorities in PKAF. The root CA in particular has no information at all on end users.
Naturally, not all the information gathered when registering someone needs to appear in their certificate. For example, a certificate issued by your employer would not necessarily contain your employee number. The separation of the ORA and OCA in PKAF means that administrative data can be collected in order to establish the legitimacy of an applicant but withheld from publication in the certificate. Such private data may be retained at the ORA without ever being sighted at the OCA or a higher level. Thus personal data can be localised in PKAF. Typically, ORAs will be operated at such sites which currently handle and control personal data, such as personnel and customer service departments.
Another benefit of the separation of ORA and OCA is that the ORA can withhold even the name of the certificate applicant, instead assigning them a pseudonym and passing that to the OCA to appear in the certificate. The mapping of real names to pseudonyms and any necessary archive of actual identities can remain entirely under the control of the ORA. Naturally, anyone depending on a pseudonymous certificate will have some interest in the conditions under which it was issued, and these will be published in the CA’s certificate policy.
In contrast with the common preoccupation with ‘100 point ID’, a CA need not gather any more data than is required for the purpose of the certificates it issues. If an organisation has already established the bona fides of a given member according to its rules, then there should be no need to also gather a passport or driver’s licence before issuing a certificate. The purpose of the certificate and the data to be gathered must be laid out in the certificate policy and compliance with the policy will be a prerequisite to the CA maintaining its PKAF certification. Through policy flexibility, PKAF thus helps control the scope of data collection, in line with the Privacy Commissioner’s National Principles.
Some claim that the so-called web of trust model for key distribution somehow offers advantages to participants’ privacy because personal details are not entrusted to any third party. But as we’ve seen, private details in PKAF are not necessarily given to the OCA. Furthermore, the use of ‘recommenders’ in the typical web of trust brings its own erosion of privacy. Trusting recommenders’ abilities is a radical jump from trusting others’ identities alone. There is no auditability in a web of trust, unless all recommenders follow standardised, transparent processes — in which case, ironically, they will start to behave more like certification authorities!
PKI will probably continue to suffer a poor reputation among privacy advocates so long as two types of misconceptions persist: first, that digital certificates are necessarily electronic passports, and second, that PKI represents a centralised network. On the contrary, PKI offers great privacy benefits including localisation of personal data, minimisation of data gathering, autonomy for communities and pseudonymity. A less threatening PKI model can be taken from the standards certification world, where certification bodies may be accredited under common guidelines without impinging on their ability to serve the particular local needs of their communities.
Stephen Wilson is Associate Director of the KPMG Certification Authority, and Chair of the Certification Forum of Australia (CFA). He currently consults to major clients in the health care, government and finance sectors. Stephen has published widely on public key infrastructure management models and government policy.
Disclaimer: the views expressed in this paper are not necessarily the views of Standards Australia, nor its technical committee IT/12/4/1.
‘Strategies for the Implementation of a Public Key Authentication Framework (PKAF) in Australia’, Standards Australia SAA MP75 1996 — executive summary available at http://www.acs.org.au/president/1996/epubs/pkaf.htm.
‘Electronic Commerce: Building The Legal Framework’, Report of the Electronic Commerce Expert Group to the Attorney General March 1998 at http://www.law.gov.au/aghome/advisory/eceg/ecegreport.html.
‘Strategies for a Peak Body for an Australian National Electronic Authentication Framework’, NOIE National Public Key Infrastructure Working Group April 1998 at <www.noie.gov.au/reports/npki/npkiworkingpartyreport.html>.
‘Establishment of a National Authentication Authority — A Discussion Paper’, NOIE 1998 at http://www.noie.gov.au/reports/authenticate.html.
‘Public Key Infrastructure Position Statement’, Roger Clarke May 1998 at www.anu.edu.au/people/Roger.Clarke/DV/PKIPosn.html.
‘National Principles for the Fair Handling of Personal Information’, Office of the Privacy Commissioner February 1998 at http://www.privacy.gov.au /news/p6_4_1.html.