Internet Security and Cryptography
Before you can adequately secure yourself and your data on the Internet, you need to first learn how data is transmitted across the Internet and how it can be vulnerable. Once you’ve learned these vulnerabilities, and common countermeasures, you’ll be much better equipped to deal with potential security threats on the Internet, and much more IT security-savvy in general. Let’s get started.
Before we go into detail about protecting yourself against some common Internet security threats, it’s probably helpful to first review some of the most common forms of attack that are attempted by criminals and hackers over the Internet.
Common Forms of Attack
- Integrity Threats – Threats to the sanctity of data itself. An example of an integrity threat would be an attempt by an intruder to modify data such as password or personal data.
- Confidentiality Threats – These types of threats include reading important stored data, such as company secrets or personal credit card details.
- Denial of Service Threats – Threats designed to overload a server’s ability to process requests, rendering it functionally inoperable.
- Authentication Threats – The intruder impersonates a legitimate user, for example a user in a Business to Business system, who is then allowed to make large financial transactions.
With this mind, then, let’s look at the main security needs of any organisation that will be operating in the e-commerce sphere.
Common Security Needs
- Confidentiality – Information must be secure. Private information such as credit card numbers cannot be accessed by unauthorised parties.
- Authentication – The origin of a message or transaciton must be clearly identified and the originator confirmed as being who they claim to be. .
- Integrity – Only authorised parties should be able to change data.
- Non-repudiation – Neither the sender nor receiver of a transaction should be able to deny that a transaction took place.
- Access Control – Facilities in an e-commerce system must be controlled so that users are only allowed to use resources that they require and are authorised to access.
- Availability – The resources of a system must be available to authorised users when they are needed by those users.
An Example of An Internet Security Attack
We’re now going to get specific about how an Internet data breach could possibly occur.
Image there are two participants in an online transaction – Alice and Bob.
They are attempting to communicate with each other securely, with very personal information being transmitted.
However, there’s an intruder afoot – Trudy. She wants to eavesdrop on Alice and Bob’s communication, intercept messages and possibly delete them.
The below diagram demonstrates the trio of participants in our little example:
Keep in mind that Alice and Bob could represent any number of possible parties participating in an Internet transaction; they could represent a Web browser and server for electronic transactions (such as online purchases), or an online banking client/server, or DNS servers, or even routers exchanging routing table updates.
Now, ask yourself this question: What could a ‘bad guy’ do to possibly provide a data breach scenario to Bob and Alice’s transaction?
The answer is: Quite a lot.
For a start:
- Eavesdrop: Intercept and read/listen to messages
- Actively insert messages into their connection
- Impersonation – Fake (spoof) source address in a packet (or any field in a packet)
- Hijacking: ‘Take over’ the ongoing connection by removing the sender or receiver, and inserting himself in their place
- Denial of Service: Prevent the service from being used by others (by overloading resources)
Obviously, it’s much, much easier to intercept and read an otherwise private message if it’s simply in a plain text format. There’s no effort required on the part of the hacker to ‘decipher’ or decrypt the message; it’s simply there in plain text for all to be read.
This is where encryption comes in.
Now imagine a scenario in which Alice and Bob’s messages are encrypted with an encryption algorithm. Alice and Bob both have an ‘encryption key’ which allows them to ‘unscramble’ the encrypted message (referred to as ciphertext). The encryption key is identical for both Alice and Bob, but the decryption key is different and is kept secret, known only to Bob and Alice. The key used to encrypt the data is known as the public key (so called because it’s publicly available – anyone can use it to encrypt their messages) and the key used to decrypt the key is private, referred to as a private key. Alice sends her private key to Bob so that he can decrypt the message sent by Alice.
Does this scenario appear more secure to you?
Actually, it’s not at all.
For a hacker to obtain access to the encrypted communication, all they would have to do is simply pretend to be Alice. There is no way that Bob can confirm whether or not the person claiming to be Alice is actually Alice.
Let’s try this again.
Imagine in this next scenario that Alice also has to provide her IP address to Bob, to confirm her identity.
Unfortunately, this isn’t secure either.
Because Trudy can simply create a packet ‘spoofing’ Alice’s IP address. Bob can’t tell the difference.
Okay, okay. How about a scenario in which, as well as providing her IP address, Alice also needs to provide a secret password before Bob can verify that it is indeed Alice and not an impostor.
Sorry, still not secure.
Trudy can simply record Alice’s packets and later perform an operation known as a playback attack, which involves ‘playing back’ the recorded packets (containing the password) to Bob.
So let’s say our goal is to avoid any kind of playback attack.
One way to do this is to introduce another step to the authentication process, in which Bob must send to Alice a nonce (referred to here as R), a special number used only once ever in a lifetime. Alice must then return R in an encrypted form, encrypted with the shared secret key.
Now we’re getting somewhere.
So we can start to see how cryptography can be useful once we introduce the nonce. The version of the communication below employs a nonce and public key cryptography.
But, wait. There’s still a potential security hole even in this mechanism of communication. It’s vulnerable to a ‘man in the middle attack’, in which Trudy simply poses as Alice (to Bob) and as Bob (to Alice), as in the below diagram.
The problem with this form of attack, and partially what makes it so difficult to defend against, is that it’s almost completely transparent – Bob receives everything that Alice sends, and vice versa – Alice receives everything that Bob sends. It all just passes through Trudy, unknowingly to both parties. Both parties in fact would be completely unaware of the ‘man in the middle’ – they could meet in person one week later and recall every aspect of the intruded-upon conversation.
One method that has been developed to overcome this dastardly form of information attack is the use of digital signatures.
Digital signatures are a cryptographic technique somewhat analogous to hand-written signatures. The sender (in this case, Bob) digitally signs a document, establishing that he is the document’s owner and creator. The digital signature is verifiable and nonforgeable. The recipient of this document (Alice) can prove to someone that Bob and no-one else signed the document.
So, to give an example digital signature for a sample message m:
Bob signs the message m by encrypting with his private key Kb, creating a ‘signed’ message, Kb(m):
Alice can now verify that Bob digitally signed the message m, and that no one else signed the message.
Now, it’s computationally expensive to encrypt long messages using a public key. The goal is to establish a fixed-length, easy to compute digital ‘fingerprint’. This can be done by applying a ‘hash function’ to the message m, and obtaining a ‘hash value’ (sometimes referred to as the message digest), H(m).
A hash function is an algorithm that takes an arbitrary block of data and returns a fixed-size bit string, the (cryptographic) hash value, such that any change to the data will almost certainly change the hash value.
Importantly, it is mathematically infeasible to modify a message without changing the corresponding hash value, and similarly it is infeasible to find two different messages with the exact same hash.
So we use a digitally signed message digest (hash value) to compare against the hashed message to check if they are equal.
This then brings about the question of how can two entities establish a secret shared key over a network?
The answer is that we us a trusted key distribution centre (KDC) acting as an intermediary between the two parties.
A KDC server shares a different secret key with each of its many registered users. The KDC allows Bob and Alice to determine a shared symmetric secret key to communicate with each other by generating a session key for shared symmetric encryption, known to both Alice and Bob.
Another way to ensure that a public key truly belongs to the person it is claiming to be from is to use the services of a Certification Authority (CA).
Such an organisation binds a public key to a particular entity (E).
E (a person or a router) first registers its public key with the CA, by providing proof of identity. The CA creates a certificate binding E to its public key. The certificate containing E’s public key is digitally signed by the CA – in essence, the CA says ‘this is E’s public key’.
Now when Alice wants Bob’s public key in order to decrypt a message sent by Bob, Alice will get Bob’s certificate and apply the CA’s public key to Bob’s certificate to get Bob’s public key.