Public Key Cryptography Concepts

The key management problemAsymmetric CryptographyMessage privacy Message signingBut who created this public key ?PK Certificates and Trusted Third PartiesWhat is meant by "identity" ?Key revocation and signature repudiationFurther Reading

The Key Management Problem

To use symmetric cryptography between N people, either:

a. N(N-1)/2 keys are needed, and each party needs securely to keep N-1 keys secret, one for each communication partner. OR

b. A single secret key is shared between N users but if 1 betrays the secret all communication is compromised. OR

c. A secretary S has N secret keys and all secure communications have to go through S. This creates a single point of failure and is not scalable.

Asymmetric CryptographyMessage privacy

Using asymmetric cryptography, keys are created in related pairs. One key in a pair can be used to encrypt a message and the other key in the pair is used to decrypt the same message. It is possible to create these key pairs so that knowledge of one can't be used to discover the other. One key in the pair can be kept secret, while the other is made public. For convenience, the public key is either used separately or stored together with the private key

For Alice to send a secret message to Bob, Bob generates a keypair and publishes his public key, keeping the other key in the pair secret. Alice uses Bob's public key to encrypt the message, sends the encrypted message to Bob, and only Bob can decrypt it using his secret key.

Asymmetric CryptographyMessage signing

Bob can also sign a message which he sends to Alice by generating a digest of the message using a cryptographic hash function and he can then encrypt this digest using his secret key. So anyone who:

has access to Bob's public key, knows that this is Bob's key, knows that Bob has kept his secret key secure and obtains a copy of this message,

can then use Bob's public key to decrypt the digest to confirm that Bob signed the message digest using his secret key. As they can use the same secure hash function to obtain the same message digest, knowing that Bob signed the digest can be considered equivalent to Bob having signed the message.

Must the hash function be secure ?

A hash function is considered cryptographically secure if:

* it is easy to compute the hash value for any given message,

* it is infeasible to find a message that has a given hash,

* it is infeasible to modify a message without changing its hash,

* it is infeasible to find two different messages with the same hash.

(source – Wikipedia)

SHA1 is thought still to have these properties, MD5 is considered broken.

How does Alice know who created the key ?

Alice and Bob might meet to exchange keys. Bob could then give Alice a copy of his public key, and assuming Alice can identify Bob, she knows she is using Bob's public key when she encrypts a message for Bob, or when she checks Bob's signature on a message. If Alice recognises Bob's voice she can phone Bob and ask him to identify the public key. A fingerprint of the key taken using a crypto strength hash function is easier to read over the phone than the whole key.

One way to answer this question depends upon how important it is to keep the messages Alice sends to Bob secret. If Alice and Bob want to go to the trouble of using cryptography, then this question probably is important, but it still might not be convenient for Alice and Bob to meet in person or phone each other to be able to exchange public keys. Perhaps they wouldn't know each other's voices or recognise the other's face.

Meet Ethel the Evil SpyEthel can intercept messages sent by Bob to Alice or by Alice

to Bob. Ethel knows the public keys of both Alice and Bob but not their secret keys. Ethel's has created bogus websites containing public keys which she claims belong to Alice and Bob but which she has created herself. If she is successful at persuading Bob and Alice to accept her bogus keys as genuine, then she can intercept and decrypt a message Alice meant to send to Bob using her bogus Bob secret key, and then encrypt it to send it on to Bob using her bogus Alice key.

Alice and Bob are sending messages to each other thinking these messages are secret, while all along Ethel is reading them, and maybe even altering them in transit. This is called a man in the middle attack.

Certificates and Trusted Third Parties

If both Alice and Bob know and trust Dave to identify the other party and sign their respective keys, then Dave's signatures on the public keys can verify who they belong to. A signature verifying the identity of the owner of a cryptographic key is called a public key certificate, or just a certificate.

For Dave to do his job well he will either have to know Alice and Bob personally, or he will have to take steps to confirm their identities. Dave is acting in the role of a Trusted Third Party (TTP) in respect of the cryptography used in connection with Alice and Bob's communications.

But what do we mean by an identity ?

Identity theft has become a lucrative crime in recent years. If an impersonator can "steal an identity" then for our purposes, identity concerns how the individual concerned is seen by gullible others and systems, rather than the whole person to whom the identity should be connected.

A good way to think about this is by combining the terms "identified" with "entity". Identity in this sense is what is in the eye of the person or agent who identifies another entity. So when we start considering binding a cryptographic key to a personal identity it might help us avoid unrealistic expectations about what crytography can do if we digress for a moment to consider the implications of identity as being a subjective matter.

Many names = Many identities ?

Personal names have many forms. DNS names are also useful, as these involve an extensible, scalable, delegated and globally unique namespace. Email addresses are useful hooks for on-line identity as security tokens can automatically be sent to them, but as with names, keys and passwords, there can be many for one individual.

You may say I still have the same identity regardless of the relationship of others to me and the names and addresses used in many connections. But I might not want to be identified the same way regardless of the connection.

How many identities do you want ?The UK Data Protection Act suggests the data connected to me

is containerised based upon a need to know. It can also be argued for privacy reasons, that the identity by which you interact with one organisation should not have to be the same as the identity with which you interact with every other organisation.

But taxpayers don't want governments to give benefits to the same person more than once. Taxation systems with personal allowances are intended to stop someone getting allowances twice in respect of different tax identities. In a sense the biometric (e.g. a photo) is an identity as it is the information that is most likely to be matched when catching someone attempting to commit crimes by using multiple or stolen identities.

How many eggs in one basket ?The practical consequence of this problem is that cryptographic

keys relating to a single individual seem likely to be multiple. You probably don't want to use the same key on your passport as on your bank card or for your private correspondence.

But we started by thinking about asymmetric cryptography as a solution to having to manage too many keys ! This is true when we think about the use of keys needed between a number of potential communicators within a bounded network. When we consider individual privacy needs, we end up potentially still needing multiple keys to authenticate ourselves and handle our communications privately with the multiple identifiers we legitimately have in different connections.

Key Revocation and Signature Repudiation

Key revocation is what you should do when your secret key is compromised.

Repudiation is what you do if someone forges your authority to prevent your authority being misused. Examples:

A payment appears on your credit card statement in connection with a purchase you never made.

A letter arrives demanding payment for something you never ordered. Someone blocks the sale of your house by impersonating a creditor.

They have a signed mortgage agreement but you never signed it. You claim your stockbroker sold your shares before the price went up

without your authority. But the stockbroker has a copy of the signature which she thinks proves you authorised the sale.

Repudiation and banks

One reason that makes us believe our money is more safe in a bank than under the mattress is that we can repudiate a payment made in error which we didn't authorise. Unfortunately in the UK the onus of proving non-authorisation in connection with phantom ATM withdrawals has been on the bank customer, rather than the onus being on the bank to prove authorisation. For UK non ATM transactions, the onus has traditionally been on the bank, but in the US the onus has been on the bank in respect of both ATM and non ATM transactions.

Repudiation is a difficult issue in connection with public key cryptography. The problem concerns the degree of guarantee that can be obtained after a secret key is notified as having been compromised, that it won't be used in error.

The key revocation problem illustrated 1

a. Ethel Evil places a very large bet on the shares of ACME Holdings going down. (Short selling.)

b. Bob Stockbroker and Alice Shareholder have a contract such that Alice instructs Bob to buy and sell shares, using emailed instructions signed using Alice's secret key, which Bob confirms using Alice's public key after checking to see if the key has been revoked for large transactions.

c. Ethel arranges for Joe Semtex, the notorious safe cracker, to carry out the theft of Alice's secret key.

The key revocation problem illustrated 2

d. Ethel also arranges for Dmitri Nyetovitch, the enigmatic botnet operator, to launch a distributed denial of service attack on the key revocation servers used by Alice.

e. One morning, Alice becomes aware that her key has been compromised on finding that the safe containing it has been blasted open.

f. Alice finds her key revocation certificate, and uploads this onto a key revocation server, which immediately replicates this revocation record to a number of clustered key revocation backup servers.

The key revocation problem illustrated 3g. Ethel uses Alice's secret key to sign an emailed

instruction to Bob to sell all of Alice's ACME shares.

h. As the number of shares to be sold is very large, Bob first checks the key revocation list to see if Alice's key has been revoked, but all the replicated servers providing this list are inaccessible. So Bob uses a copy of this list which is in his browser cache, and this copy doesn't contain Alice's key.

i. Bob sells Alice's ACME shares based on the forged instruction which he believes to be genuine. The volume of trading causes the price of ACME shares to fall through the floor.

The key revocation problem illustrated 4

j. Ethel buys back the 1,000,000 ACME shares at half the $10 price she shorted these at, making a profit of $5,000,000.

k. When Alice discovers that Bob has sold these shares based on a forged instruction and has lost $10,000,000 on them, she demands that Bob recompense her for this loss.

l. Bob has logged all of his actions based on the written contract he has with Alice, and believes that he checked whether Alice's key had been revoked.

The key revocation problem illustrated 5

The contract between Bob and Alice had specified that for transactions greater than $100,000 Bob would have to check the key revocation servers to see if Alice's key had been revoked prior to using this as authority to buy and sell shares.

But the contract between Bob and Alice didn't specify what Bob should do in the event of all the key revocation servers being inaccessible. This contractual ambiguity will be one that Bob and Alice's lawyers are likely to fight out in court and could either cost Bob everything he has or a substantial part of Alice's net assets. Alternatively the legal fees will be enough that both Alice and Bob will lose and the lawyers will win.

Key revocation or shorter key lifetimes ?

To avoid the above problem or of key revocation lists growing indefinitely, keys have to be given a finite lifetime, so that they expire naturally and information about good and bad ones can be managed. Some security researchers are still sent messages encrypted using public keys for which they lost the private keys years ago, before it became accepted that keys should be given a limited lifetime.

One approach to this problem is for keys to be issued with a very short lifetime. This is similar to the approach used by Kerberos in respect of session keys with a lifetime of a few hours. In this situation the complexity of revocation certificates and servers is unneccessary.

Recommended ReadingMan in the middle attack: http://en.wikipedia.org/wiki/Man_in_the_middle_attack

Public key certificate: http://en.wikipedia.org/wiki/Public_key_certificate

Trusted Third Party: http://en.wikipedia.org/wiki/Trusted_third_party

Fingerprint biometric forgery: http://www.theregister.co.uk/2002/05/16/gummi_bears_defeat_fingerprint_sensors/

Phantom ATM Withdrawals: http://www.phantomwithdrawals.com/

Short selling: http://en.wikipedia.org/wiki/Selling_short

Denial of service attack: http://en.wikipedia.org/wiki/Denial-of-service_attack

MD5 verifies rogue certificates: http://www.zdnet.com/blog/security/ssl-broken-hackers-create-rogue-ca-certificate-using-md5-collisions/2339