By Andre Griffith
In previous weeks we looked at the boring science, mathematics and technology underlying securing the characteristics of authenticity, confidentiality, integrity and non-repudiation in business transactions in the digital realm. In particular we looked at asymmetric key encryption and how it works in principle. At the end of it all, we acknowledged that in practice, it is unwieldy to use solely asymmetric technologies in producing electronic records of contracts and noted that symmetric technologies are also used in tandem with the asymmetric.
In particular we noted that in practice, the use of the public key is largely restricted to “signing” documents by encrypting some sort of checksum which unique to any given message, thus ensuring authenticity, integrity and non-repudiation, and for exchanging symmetric keys which are far more efficient at encrypting communications (for confidentiality). I hope that using the device of our hypothetical (yet perhaps topical) example of a three-way transaction between two companies and a government went some way in providing a context that assisted understanding the technology and I’m happy to say that most software implementing encryption is a great deal easier to use than these articles may have implied since much of the mechanics is abstracted from the user. Despite the inherent complexity of the subject matter, it is useful to understand at a conceptual (as opposed to detailed level) what is involved in order to have some confidence in a process that your business depends on. This week we shall be examining the Public Key Infrastructure (PKI) which primarily comprises the technical, administrative and legal environment that is necessary to support the use of asymmetric public key technology (and by extension accompanying symmetric technologies) to enable electronic commerce.
In both part I dealing with traditional paper-based contracts and in part II dealing with their electronic equivalents, we conceded that we had glossed over the issues relating to the initial establishment of the bona fides of the parties to the transactions. We assumed in the case of non e-commerce transactions that John was already familiar with Jane’s signature just as in the ecommerce case we assumed that all the parties had established that the public keys were indeed associated with the persons under consideration, but at the end of part III we acknowledged that there was a valid question to be asked i.e. how did Jane and John know that the public keys they received were in truth associated with the persons they purported to be associated with. In the electronic realm, this assurance is achieved through what is called a public key infrastructure (PKI), which is a mechanism for creating, assigning, distributing and verifying public keys.
Anything other than the most rudimentary of business relies in some measure on trust involving as it does granting of credit, honouring warranties and like issues. As is commonly said in the Middle East however, trust in The Almighty but tie your camel. Tangible proof of contracts represents the act of tying the camel and the Public Key Infrastructure (PKI) provides the means by which electronic contracts can be recorded.
At the heart of the PKI is a “Certifying Authority”. This is a trusted body that is responsible for determining the bona fides of an organization and issuing it with a “key certificate” which essentially is a certificate attesting that a given public key is associated with a given entity. A certificate can be an “authentication certificate” which verifies your identity or it can be a “digital signature certificate”, which has much more stringent requirements on it. In the case of an authentication certificate, the CA itself can generate the key pair, assign the public key to Jane’s company and vouch for Jane’s identity to the outside world. In the case of a digital signature certificate, it is essential that only the user of the certificate has access to the private key, thus the CA, subject to some well-publicised rules of procedure would receive only the public key from the user and issue a certificate accordingly. The certifying authority (CA) is also responsible among other things for publishing a list of organizations and their public keys, and even more importantly to maintain a “revocation list” (RL), which publishes records of certificates that have been revoked.
There is more than one model on which a PKI can be implemented, however the one that is probably most appropriate in considering the establishment of e-commerce infrastructure in Guyana would be a hierarchical trust model, where a “root Certificate Authority” sits at the top of a hierarchy and certifies other CA’s below it. As an example, the Bank of Guyana can be designated as a “root Certificate Authority” for all of the financial institutions in Guyana. The BOG would then certify the public keys of Republic Bank, Demerara Bank, GBTI, ScotiaBank (Guyana), NBS, Hand-in-Hand Trust and the various banks, trusts, insurance companies &c.
These institutions can in turn become certifying authorities for their account-holding clients.
Each client could if necessary become a certification authority for its relevant employees such as purchasing agents, finance officers, account signatories etc. It should be evident that the foregoing describes a hierarchy of authority hence the name “hierarchical”. It should be immediately apparent where the revocation list becomes important. Should your purchasing manager be terminated, you had better run (not walk) to your in-house certifying authority and ensure that her certificate is revoked and published as such lest you suddenly find yourself with a significant liability from a disgruntled employee.
Similarly to the hierarchy of the financial institutions which can extend down to individual companies by virtue of their being clients of the institution, there can be a parallel hierarchy for government institutions. A “root CA” for the government can possibly exists in the Office of the President which can issue certificates for all Ministries and these in turn can issue certificates for state agencies in their portfolio. These certificates could conceivably attest to the competence of the particular government agency to address a particular matter.
For example if you wished to enter into a transaction with the Lands and Surveys Commission regarding the lease of land in a given region, the certificate could conceivably attest to the competence of that entity to address that matter as opposed to the local NDC.
One obvious question is “who certifies the root CA” and the answer is simple. The root CA issues its own certificate. That is to say the root CA generates its own digital signature and authentication key pairs and publishes its own certificate that contains the public keys. The root CA can then certify other CA’s lower down in the hierarchy and these in turn can certify others below them.
It should be evident by now this model totally breaks down if the Certification Authority cannot be trusted. The CA has to be trusted to be meticulous in its investigation of any entity that applies for either an authentication or a digital signature certificate.
It further has to have in place, sound technical and administrative systems to ensure that its own certificate is not compromised thus allowing for entities masquerading as the CA to issue false certificates. The most secure method is for the CA to isolate the system containing its private key from any network, and to strictly control physical access to its premises and to the machine on which the key is stored. To wrap up this series next week, we shall take a look at some standards and common platforms for electronic commerce.
