Gamified Intelligent Cyber Aptitude and Skills Training (GICAST)
Gamified Intelligent Cyber Aptitude and Skills Training (GICAST)

Start this free course now. Just create an account and sign in. Enrol and complete the course for a free statement of participation or digital badge if available.

Free course

Gamified Intelligent Cyber Aptitude and Skills Training (GICAST)

3.2 Digital signatures and certificates

This section is part of the amber and green pathways.

Download this video clip.Video player: cyber_security_week5_video.mp4
Skip transcript


We’ve already seen that exchanging encrypted documents using public key means that Alice and Bob each have to generate their own key pairs, comprised of a public key and a private key. Before they can exchange documents, they first need to send one another copies of their public keys. Then, Alice can send secrets to Bob by encrypting documents using Bob’s public key, and Bob can share secrets with Alice using her public key. But there’s more you can do with public key cryptography than just hiding secrets. It’s also possible to encrypt data using the private key, which might sound like a pointless thing to do.
After all, a file encrypted using Bob’s private key can be decrypted by anyone who has a copy of his public key. And Bob gives that away to anyone who asks, including evil Eve. So, if encrypting using the private key isn’t going to protect any secrets, what’s it for? Whilst the encrypted file can be decrypted by any copy of Bob’s public key, it can only have been encrypted by the corresponding private key. If Bob has obeyed the rules and not shared his private key, then the documents can only have come from Bob. Encrypting using the private key is therefore a way of authenticating data.
Now, anyone wanting data from Bob can download a copy of the encrypted document and a copy of his public key. They decrypt the file using the public key and can satisfy themselves the data is genuine. But it’s not quite as simple as that. Bob’s public key is only authenticated by his email address. If Eve can steal Bob’s email address, there is nothing to stop her generating new keys under Bob’s identity. Eve can now send false documents or malware in Bob’s name. Alice will open them, because she trusts Bob. Oh dear. Bob can prevent Eve impersonating him by certifying his public key.
Here, a so-called trusted third party, which can be another individual, a government, or a private company, will confirm that Bob’s key is genuine. To do this, Bob must prove his identity to them using personal information that isn’t readily available to Eve, such as his passport, business registration, or birth certificate. The certification body can either certify the public key itself or provide Bob with a digital certificate containing his public key.
As well as the holder’s public key, a certificate contains a unique serial number, the name of the certificate’s owner, the name of the agency that issued the certificate, the agency’s digital signature, proving it is authentic, the issue date of the certificate and the date it will expire, after which it can no longer be considered valid, and a hash value used to check that the certificate has not been altered since it was issued. As well as individual use, certificates are used to authenticate software downloads, such as those from app stores. Certificates are also used by websites who presents copies of their certificates to web browsers. The browser checks that the certificate is authentic, proving that the site is genuine.
If the certificate is invalid, the browser will warn the user they may be navigating to a page that has been hijacked, and it will offer them an opportunity to stop. Certificate holders have to be careful to renew their certificates before they expire. Otherwise, they might find users avoiding their websites or that their software downloads are not valid. This happened to Apple in November 2015, when millions of users could not update apps on their Macs. Fortunately, a new certificate was quickly issued, and everything worked again.
End transcript
Interactive feature not available in single page view (see it in standard view).

Hashing can show that data has not changed in transmission, but on its own cannot demonstrate that the data originated with its supposed author. To do that, a digital signature should be used.

Digital signatures use the sender’s private key to encrypt the hash. Previously, you learned how documents can be encrypted with a public key which can be used by anyone, but can only be decrypted using the corresponding private key known only to the owner.

Encrypting data using the private key isn’t suitable for securing secrets (as anyone with access to the public key could decrypt it). However, it is perfectly possible to encrypt a hash using the private key so that the hash can be decrypted and compared by anyone possessing the matching public key. This can be used to provide authenticity since the encrypted hash must have been produced by the holder of the private key – hence the name digital signature.

Case study 1: Alice and Bob

Imagine that Alice wants to send the company’s quarterly profit statement to Bob, who works in the financial markets, for public announcement. Both Alice and Bob want confidence that the quarterly profit statement has not been intercepted by Eve en route and altered.

Alice will therefore produce a hash of the quarterly profit statement and then encrypt this with her private key to produce a digital signature. Alice will then include the digital signature with the quarterly profit statement and send this to Bob. Alice may also encrypt the quarterly profit statement and the encrypted hash with Bob’s public key so that all details of the message remain secret (depending on any time-bound sensitivities she may or may not encrypt this with Bob’s public key).

Upon receipt Bob will decrypt the digital signature using Alice’s corresponding public key to reveal the hash (again depending on any time-bound sensitivities he may initially decrypt the entire message using his private key). Bob will then calculate a hash of the quarterly profit statement and then compare this with the encrypted hash that he received from Alice. If the hashes are the same then both Bob and Alice can be confident that the quarterly profit statement was not altered en route by Eve.

Digital signatures do not provide us with complete confidence of the author or originator. Just because a digitally signed document claims to come from a person or a company it doesn’t mean that it actually did, a malicious individual could masquerade as the sender by producing their own public/private key pair and using these to produce digital signatures.

Case study 2: Alice and Bob

Imagine that a digitally signed business invoice arrives in Alice’s mailbox from Bob. She uses Bob’s public key from a public key server to decrypt the digital signature and validate the business invoice by comparing the hashes. Alice, assuring herself that it is Bob (as the hashes are the same), follows the instructions and transfers money to the account details in the business invoice.

A few weeks later, Alice receives an angry email from Bob because he has not been paid. After a bank investigation she finds out that she had transferred the money to Eve by mistake – so what went wrong?

It’s clear that the business invoice and the associated signature did not come from Bob, instead the signed business invoice actually came from Eve. Eve used Bob’s personal information to create a new key pair in Bob’s name and placed a copy of the public key on a public key server. Eve then used her corresponding private key to sign the business invoice and send it to Alice.

Alice, convinced that the document was a genuine business invoice from Bob (as it included what she believed to be his digital signature), followed the instructions and paid money into an account belonging to Eve – oh dear!

Digital certificates help us overcome this problem. A digital certificate is a means of binding public keys to their owner. These are issued by Certificate Authorities (CAs) who validate the owners of public keys. The CA does this by validating (through various processes) the identity of the owner of the public key. Once it has done this it will bind the public key to a digital certificate and sign it using its private key to attest authenticity. The CA’s public key is available to all parties who need to validate the CA’s assertion of public key ownership.

This figure illustrates the typical structure of a digital certificate. The certificate primarily associates a user with his public key. A digital certificate is issued by a Certification Authority (CA) and it validates the information in the certificate. Digital certificates are issued to both users as well as devices and software programs (hardware and software assets). Software programs typically use them for communicating with their peer programs. You will see examples of protocols that use digital certificates later in the week. This certificate conforms to the X.509 standard from the International Telecommunications Union (ITU-T).

This is a grid containing information typical of a digital certificate. There is information about Version, Serial Number, Signature Algorithm ID, Issuer (CA) X.500 Name, Validity Period, Subject X.500 Name, Subject Public Key Info, Issuer Unique ID, Subject Unique ID, Extension, CA Digital Signature.
Figure 13 A typical structure of a digital certificate

Case study 3: Alice and Bob

So, using a Certificate Authority prevents Eve from creating a key pair of her own, and claiming that the corresponding public key is Bob’s. If Eve were to now send a business invoice appearing to be signed by Bob, when Alice uses Bob’s validated public key to try and decrypt the hash and compare them, this will not work; she would know that something was wrong, and (hopefully) not transfer money to Eve.


Take your learning further371

Making the decision to study can be a big step, which is why you'll want a trusted University. The Open University has 50 years’ experience delivering flexible learning and 170,000 students are studying with us right now. Take a look at all Open University courses372.

If you are new to university level study, we offer two introductory routes to our qualifications. Find out Where to take your learning next?373 You could either choose to start with an Access courses374or an open box module, which allows you to count your previous learning towards an Open University qualification.

Not ready for University study then browse over 1000 free courses on OpenLearn375 and sign up to our newsletter376 to hear about new free courses as they are released.

Every year, thousands of students decide to study with The Open University. With over 120 qualifications, we’ve got the right course for you.

Request an Open University prospectus371