We have a problem in modern society … how can we be sure that someone really is who they say they are? On the Internet we normally trusted third party that both parties trust. In many cases when we discuss secret communications we have Bob and Alice, so let’s call our pair Bob and Alice, and we will define their trusted person as Trent, who is the only person in the world that both Bob and Alice trust. Unfortunately Trent’s fees are high, so they want to minimise the things that he has to do, and must thus use Trent to set-up a secret channel for them to communicate. For this Trent will create a secret box, which can be passed between Bob and Alice, who will have secret keys for it. If they loose them, hopefully Trent will have a copy of the key, just in case.
Messy Divorce
Bob and Alice and going through a difficult time, and now they only communicate through their lawyer, who they both trust, but want a way to identify each other and communicate in a secret way (so that Trent doesn’t actually see them messages). Unfortunately they cannot afford any expensive lawyer fees for their communications, so how do they use Trent to create a secret box for their communications? Well they can use a proposal known as Kerberos.
Trent Gets a Box and a Key
So Alice goes to Trent and says that she has to prove her identity to Bob, and vice-versa. For this Trent will make a special key for a box, and will make a copy for Bob and Alice (he might also keep a copy for himself, just in case they lose them – this technique is know as key escrow). Trent will then take a photograph of Alice, and write down the date and time on it, and the amount of time he can verify Alice for. He will then put it into the box, and gives the box to Alice, along with the key. Along with this he will give her a sealed letter for the attention Bob which has his stamp on it. Inside will be a photograph of Alice that he took, and the secret key, along with the date/time that he created the key. With key escrow, Trent will keep a copy of the key, just in case that Bob and Alice loose their keys, but if even Bob and Alice do not want this, then Trust must prove that he does not have any other keys. In this way Trent will not be blamed for any leakage of the information in the box.
Alice Sends the Box
Alice then goes home, and then puts her photograph in the box, and locks it with the secret key. She then passes the box, without the key, along with the sealed letter to Bob. Bob opens the sealed letter, which has a key inside to open up the box, and which has the photograph that Trent took of Alice. Bob then opens the box with the secret key provided by Trent, and takes out the photograph that Alice has provided. If it is the same as the one that Trent put in the sealed letter, Bob thus verifies Alice’s identity.
Now we have a Secret Box … and no lawyer
Bob and Alice now have the same key to open and close the secret box, and can now use it to send secret messages to each other. No-one else will have that unique key, thus any messages in there must have been provided by Bob and Alice. Now they can both define the terms of the divorce without being billed for more solicitor fees for their messages.
The Encryption Protocol
If you are interested, here is the actual encryption proposal based on this example:
As we become more dependent on the Web, we can never be 100% sure that everything is correct and as it should be. This might relate to receiving an email from someone who says that they know you, but how can you tell if the person is genuine? The email address looks fine, but the email content does not have the same writing style as the person who normally writes from that email address. Unfortunately there is very little that we can do, at present, to determine if this is genuine, but things are changing, and it is trust that is becoming the key element of how we interact with the Web.
Bruce Schneier highlights this, in that we are entering a new phase, and defines that:
Trust and cooperation are the first problems we had to solve before we could
become a social species. In the 21st century, they have become the most important
problems we need to solve—again.Our global society has become so large and complex that
our traditional trust mechanisms no longer work.
Kerberos (The Three-headed Beast)
A three-headed version of Kerberos
Users must thus ask themselves who they trust on the Internet? We can use hash signatures to determine if information has been changed, but how can we be sure that the person who created the data, and signed it, is actually the person who they say they are. So the only way we can properly identify two users to each other is to use a trusted partner who both parties trust, and thus we introduce the concept of Trent, who is trusted by both Bob and Alice. In a legal system, Trent is a lawyer, who is trusted enough to see-through a house sale, and to take the money from Bob’s account, and then place it in Alice’s account, and where Trent has to places the funds in his own account as part of the transfer. Bob and Alice trust Trent enough that he will not deposit the money in his account, and then run-off with the money. Trust is thus a key part of our lives and as citizens we have developed strong trust relationships, such as with the legal systems, the police, and with our banks. We thus trust our banks to be able to look after our money, and not to go and use it to invest in doggy deals, and use the money to pay high salaries to their executives — or do we? If not, then are trust has reduced, as banks at one time were seen to be a safe place to deposit money, and then be able to take it out again.
So we now have three parties involved: Bob, Alice and Trent. So where does Kerberos come in? Well Kerberos (or Cerberus) was defined in Greek and Roman mythology as, typically, a three-headed dog. It is often known as the hellhound that guards the gates of the Underworld, in order to stop those who have crossed the river Styx from escaping. As we’ll find both the description of the three headed beast fits the three way communication, and also that the protocol is a bit of a beast.
The Detail of the Encryption
One of the best protocols for implementing this trust infrastructure is Kerberos. It is fairly complex in its implement, but it supports both the security of the transmitted data between Bob and Alice, and also proves the identity of both Bob and Alice. So with the Kerberos protocol, Alice and Bob first deposit their secret keys, and will define their unique identifies (such as their email addresses). Trent will then be trusted to store these keys. What we need now is to generate a session key between Bob and Alice that they can use, and also to be able for Trent to prove Alice’s identity to Bob, and also Bobs identity to Alice. An example is here:
Step 1: First Alice sends her identity, and Bob’s to Trent, who will then find the keys where relate to them.
Step 2: Next Trent creates a random key to be used for the session key, and create a Timestamp (T), a Lifetime (L), which define the starting time for the trust relationship, and how long it will be valid for. He will then create two parts to send back to Alice:
EA(T,L,K,B) and EB(T,L,K,A)
where is the first part is encrypted with Alice’s secret key, and the other part is encrypted with Bob’s secret key.
Step 3: Next Alice will decrypt the first part, and can thus determine T (the timestamp), L (the lifetime), K (the session key) and B (Bob’s Identity). Alice now knows the session key (K), and now uses it to encrypt the Timestamp (T) and Alice’s Identity (A) to Bob, along with the second part of the message from Trent [EB(T,L,K,A)]:
EK(T,A) and EB(T,L,K,A)
Step 4: Bob will then decrypt the second part, and determines the session key (K), which can be used to decrypt the first part. He will then check Alice’s identity is the same as the one that Trent sent.
Step 5: Bob takes the timetable and add one onto it, and sends back to Alice:
EK(T+1)
Step 6: Alice then decrypts with the session key, and checks the timestamp. If it checks with the expected value, then Bob has proven his identity. Bob and Alice and now communicate using the session key, and be secure, as only Trent will know the session key.
So Bob and Alice trust Trent! The key fundamental element of this, is that Bob neverhas to communicate withTrent, as he knows that the only person who has his key is Trent, so he is the only one able to encrypt the information contained within the information sent by Alice. Alice then cannot change her identity, as Bob will be able to determine this by checking what Trent has said is Alice’s identity is, with the identity that Alice produces, using the session key.
So What?
So let’s relate this to real life. Bob and Alice trust Trent, but want a way to identify each other and communicate in a secret way. So Alice goes to Trent and says that she has to prove her identity to Bob, and vice-versa. For this Trent will make a special key for a box, and will make a copy for Bob and Alice (he might also keep a copy for himself, just in case they lose them). Trent will then take a photograph of Alice, and write down the date and time on it, and the amount of time he can verify Alice for. He will then put it into the box, and gives the box to Alice, along with the key. Along with this he will give her a sealed letter for the attention Bob which has his stamp on it. Inside will be a photograph of Alice that he took, and the secret key, along with the date/time that he created the key.
Alice goes home, and then puts her photograph in the box, and locks it with the secret key. She then passes the box, without the key, along with the sealed letter to Bob. Bob opens the sealed letter, which has a key inside to open up the box, and which has the photograph that Trent took of Alice. Bob then opens the box with the secret key provided by Trent, and takes out the photograph that Alice has provided. If it is the same as the one that Trent put in the sealed letter, Bob thus verifies Alice’s identity.
Bob and Alice now have the same key to open and close the secret box, and can now use it to send secret messages to each other. No-one else will have that unique key, thus any messages in there must have been provided by Bob and Alice.
Digital certificates support three main functions. The first is to provide a container for your public and your private key. If you want to purchase a digital certificate, the issuer will send you a digital certificate with both the public and the private key on it. So what do we do with this? Well if we have encrypted some data with the private key, we must send the recipient our public key, so the second usage is to strip-off the public key and add it to a digital certificate which is sent to the recipient, who can use it to decrypt the encrypted message. The third usage is related, but has a different function. For this the digital certificate is used to identity an object, such as the sender of a message. In this way the sender signs something in the message with their private key, and then distributes the public key with the certificate, and the recipient gets the signature and can verify the send.
Certificate store
It can be quite cumbersome to send the digital certificate each time we want to prove our identity or to decrypt some encrypted data, so we normally store our certificate in a repository, so that it can be used again (otherwise we can add keys to a key ring). This is either on the local machine, or can be stored on a trusted certificate repository. The screen shot on the right-hand side shows an example of my certificates, where I have stored the certificates for login.live, login.oracle, and so on. Once I accept these certificates, they are then trusted on subsequent visits. It is thus important that users check these certificates when they are first accessed, so that they are checked for their credibility. Unfortunately most users do not check them, and can end-up with certificates which a malicious or, at least, do not provide the right level of verification. For high-risk accesses, such as to your bank or for e-commerce applications, you need to be sure that the certificate has credibility with you.
As we will find the key elements of a digital certificate are: the issuer, the serial number, the date when it is valid from and to, and the public and private keys. If you trust the issuer to make checks on the entity, then you can trust the certificate which has been signed by them. An understanding of who can issue certificates, and the checks that they make is thus important. I sign many PDFs for student references with a self-signed digital certificate … which has absolutely no credibility at all … but the little padlock at the bottom of the PDF looks good though. Basically I have signed it myself, to say that I am me, but anyone else can do the same.
So what about Bob and Alice (and Eve)?
It is possible for Bob to sign a message with his private key, and that this is then decrypted by Alice with her public key? There are many ways that Alice could get Bob’s public key, but a major worry for her is that who does she trust to receive his public key? One way would be for Bob to post his public key on his web site, but what happens if the web site is down, or if it is a fake web site that Alice uses. Also if Alice asked Bob for his public key by email, how does she really know that Bob is the one who is responding? Thus we need a method to pass public keys, in the verifiable way. One of the best ways is to provide a digital certificate which contains, amongst other things, the public key of the entity which is being authenticated. Obviously anyone could generate one of these certificates, so there are two ways we can create trust. One is to setup a server on our own network which provides the digital certificates for the users and devices within an organization, or we could generate the digital certificate from a trusted source, such as from well-known Certificate Authorities (CAs), such as Verisign, GlobalSign Root, Entrust and Microsoft. These are generated by trusted parties and which has their own electronic thumbprint to verify the creator, and thus can be trusted by the recipient, or not. If you want to understand how digital certificates are created, I setup a link for you to create your own certificate:
The major problem that we now have is how to determine if the certificate we get for Bob is creditable, and can be trusted. The method used for this is to setup a PKI (Public Key Infrastructure), where certificates are generated by a trusted root CA (Certificate Authority), which is trusted by both parties. As seen in Figure 1, Bob asks the root CA for a certificate, for which the CA must check his identity, after which, if validated, they will grant Bob a certificate. This certificate is digitally signed with the private key of the CA, so that the public key of the CA can be used to check the validity of it. In most cases, the CA’s certificate is installed as a default as a Trusted Root Certificate on the machine, and is used to validate all other certificate issued by them. Thus when Bob sends his certificate to Alice, she checks the creditability of it (Figure 2), and if she trusts the CA, she will accept it. Unfortunately, the system is not perfect, and there is a lack of checking of identities from CA, and Eve could thus request a certificate, and be granted one (Figure 3). The other method is to use a self-signed certificate, which has no creditability at all, as anyone can produce a self-signed certificate, as there is no validation of it. An example of this is shown on the right-hand side, where a certificate has been issued to Bill Buchan (even though the user is Bill Buchanan).
Figure 1 Getting a certificate
Figure 2 Alice checks the certificate
Figure 3 Eve spoofs Bob
Thus our trusted root CA, which we will call Trent, is trusted by both Bob and Alice, but at what level of trust? Can we trust the certificate for authenticating emails, or can we trust it for making secure network connections? Also, can we trust it to digital sign software components? It would be too large a job to get every entity signed by Trent (the root authority), so we introduce Bert, who is trusted by Trent to sign on his behalf for certain things, such as that Bert issues the certificate for email signing and nothing else. Thus we get the concept of an intermediate authority, which is trusted to sign certain applications (Figure 4), such as for documentation authentication, code signing, client authentication, user authentication, and so on.
Note that there are typically two digital certificates in use. The one that is created by the CA that has both the private and public key on it (and can be stored on a USB stick, so that the encryption keys can be recovered at any time), and there is one that is distributed which does not have the private key (for obvious reasons).
Figure 4 Trusted root CA, intermediate CA and self-signed
Digital certificate types
Typical digital certificate types are:
IKE.
PKCS #7.
PKCS #10.
RSA signatures.
X.509v3 certificates. These are exchanged at the start of a conversion to authenticate each device.
A key factor in integrated security is the usage of digital certificates, and are a way of distributing the public key of the entity. The file used is typically in the form of X.509 certificate files. Figure 5 and Figure 6 shows an example export process to a CER file, while Figure 7 shows the actual certificate. The standard output is in a binary format, but a Base-64 conversion can be used as an easy way to export/import on a wide range of systems, such as for the following:
The CER file format is useful in importing and exporting single certificates, while other formats such as the Cryptographic Message Syntax Standard – PCKS #7 Certificates (.P7B), and Personal Information Exchange – PKCS #12 (.PFX, .P12) can be used to transfer more than one certificate. The main information for a distributable certificate will thus be:
The entity’s public key (Public key).
The issuer’s name (Issuer).
The serial number (Serial number).
Start date of certificate (Valid from).
End date of certificate (Valid to).
The subject (Subject).
CRL Distribution Points (CRL Distribution Points).
Authority Information (Authority Information Access). This will be shown when the recipient is prompted to access the certificate, or not.
Thumbprint algorithm (Thumbprint algorithm). This might be MD5, SHA1, and so on.
Thumbprint (Thumbprint).
The certificate, itself, can then be trusted to verify a host of applications (Figure 4.20), such for:
Server authentication.
Client authentication.
Code signing.
Secure email.
Time stamping.
IP security.
Windows hardware driver verification.
Windows OEM System component verification.
Smart card logon.
Document signing.
Figure 5 Exporting digital certificates
Figure 6 Exporting digital certificates
Figure 7 Digital certificate
Figure 8 Options for signing
So what’s the problem?
Fake or real?
The theory of creating a public and private key using RSA is sound, and this has proven to be secure (although the number of bits required to keep it secure increases by the day). Unfortunately few people actually know how it works. So, to test you, ask yourself these questions:
When was the last time that you checked the credibility of the bank you are visiting?
When was the last time you accepted a certificate, even though it had problems?
Would you know where to go in a browser to find the details of a certificate, and could you actually interpret them correct?
Do you know how your software components on your system are verified for their credibility, and that they can from their original source?
Do you know who the most creditably signers of certificates are? Is Google a signer? Is GlobalSign a signer?
If the answer to any of these is “I don’t know”, we have problems the PKI, as it should be there to, unfortunately, protect the end user, but obviously it isn’t.
Unfortunately many people when faced with a certificate will not actually know if the CA is a credible one, or not, and this is the main weakness of the PKI/digital certificate system. There are many cases of self-signed certificate, and of certificates which are not valid, faking the user.
Presentation
There is a demonstration of digital certificates at:
If you’re interesting in methods of authentication, please view:
We have a problem in modern society … how can we be sure that someone really is who they say they are? On the Internet we normally trusted third party that both parties trust. In many cases when we discuss secret communications we have Bob and Alice, so let’s call our pair Bob and Alice, and we will define their trusted person as Trent, who is the only person in the world that both Bob and Alice trust. Unfortunately Trent’s fees are high, so they want to minimise the things that he has to do, and must thus use Trent to set-up a secret channel for them to communicate. For this Trent will create a secret box, which can be passed between Bob and Alice, who will have secret keys for it. If they loose them, hopefully Trent will have a copy of the key, just in case.
Bob and Alice and going through a difficult time, and now they only communicate through their lawyer, who they both trust, but want a way to identify each other and communicate in a secret way (so that Trent doesn’t actually see them messages). Unfortunately they cannot afford any expensive lawyer fees for their communications, so how do they use Trent to create a secret box for their communications? Well they can use a proposal known as Kerberos.
If you are interested, here is the actual encryption proposal based on this example:
So let’s relate this to real life. Bob and Alice trust Trent, but want a way to identify each other and communicate in a secret way. So Alice goes to Trent and says that she has to prove her identity to Bob, and vice-versa. For this Trent will make a special key for a box, and will make a copy for Bob and Alice (he might also keep a copy for himself, just in case they lose them). Trent will then take a photograph of Alice, and write down the date and time on it, and the amount of time he can verify Alice for. He will then put it into the box, and gives the box to Alice, along with the key. Along with this he will give her a sealed letter for the attention Bob which has his stamp on it. Inside will be a photograph of Alice that he took, and the secret key, along with the date/time that he created the key.
billatnapier 