Multi-factor Authentication

There are three regulatory approved factors of authentication, all forms of authentication can be grouped under one of the following:

• Something you know
• Something you have
• Something you are

Two-factor authentication is when two of those three authentication types is used in conjunction with each other. The most commonly seen use of this is debit/credit cards(something you have) with a pin(something you know).

Something you know

The weakest form of the three and the most commonly seen in the form of passwords or pins. One of the most troublesome issues with this form is that there is no regulation around how it is kept secure. A password can be shared or exposed through many methods without the keepers knowledge. Often there are technical constraints imposed on the creators of passwords which limits their entropy and the keeper needs to be able to remember them which makes it easy for them to be guessed.

Something you have

This form of authentication has been around for centuries, most commonly seen in the form of a key to a lock. The formal description for this is that the key embodies a shared secret between the lock and the key.
There are four ways of attacking such a system:

• Attack the authenticator or management system to try determine the secret.
• Steal the 'something you have'
• Make a copy of the 'something you have'
• A man-in-the-middle attack where the attacker sits in between the communication channel of each entity

Something you are

The strongest factor of authentication and typically seen in the form of biometrics, something you are can compose of many things such as finger prints, iris scans, voice patterns etc. They are very susceptible to replay attacks.

Cookies

Cookies were originally designed to add persistence to the state, a website or user had taken in the past. Although cookies can not contain virus' or malware. In the modern web environment, cookies perform several critical functions. The most common of which is authentication cookies, used to know if a user is logged in or not.

The current specification (October 2011) for cookies is rfc6265

The types of cookies

• Session Cookie
• Persistent Cookie (also known as tracking cookies)
• Secure Cookie
• Http Only Cookie
• Third Party Cookie
• Super Cookie
• Zombie Cookie

Session Cookie

This type only lasts for the duration the user is on the website. To be a session cookie, no 'Expires' directive is provided when it is created.

Persistent Cookie

This type will outlast user sessions and has a max age of 1 year. Each time the site is visited the initial value set in this cookie will be provided. This could contain how the user originally came to the site, which is why it is also known as a tracking cookie.

Secure Cookie

This type has a secure attribute enabled and can only be used through HTTPS, ensuring encryption when it is transmitted between the client and the server.

Http Only Cookie

Supported by most modern browsers, this type is transmitted only when transmitting HTTP/HTTPS requests. With this, the access by client side javascript or other non-html code is mitigated. This does not totally eliminate the risk through XSS.

Third Party Cookie

This type are ones that have the domain set to a different one to the address being visited. Advertisers use this commonly to track a users browsing history.

Super Cookie

This type has a domain set as merely a top-level suffix, such as .com - security settings usually prevent this type.

Zombie Cookie

This type is recreated by other means automatically after the user has deleted it. This could be done through a variety of ways such as local flash storage.

A web browser is generally accepted to be able to store at least 300 cookies of 4Kb each and at least 20 cookies per server or domain.

Three Types of Access Control

Administrative

These security controls are put in place to define and guide employee actions in a workplace when dealing with sensitive information. E.g. Policy might dictate that HR do background checks on all employees with access to sensitive information.

Technical

These are devices, processes, protocols and other measures used to protect C.I.A of sensitive information. These might include logical access systems (Lock and key), encryption systems, antivirus systems, firewalls etc

Physical

Security controls are devices and means to control physical access to sensitive information and its availability. Examples could be a physical access systems (fence, guards etc), physical intrusion detection systems (motion sensor, alarms etc) or physical protection systems such as fire alarms, backup generators.

RSA and DSA

DSA (Digital Signature Algorithm) is an Asymmetric encryption algorithm that is known for being fast at cryptographically signing but slow at verifying. Slow at encrypting but fast at decrypting.
RSA (named after its published creators Rivest, Shamir and Adleman) and is also an Asymmetric encryption algorithm.

To define the difference between Asymmetric and Symmetric encryption: Symmetric relies on a single private key mixed with secret input - you can use block or stream ciphers. Asymmetric uses a combination of a public and private keys and require fixed bit lengths such as 1024, 2048 etc. The public key is allowed to be distributed so long as the private key remains secure. The private key is used for digitally signing where the public key can be used to verify the integrity of that.

The encryption is done through the intended recipients public key and the creators private key, then the combination of the recipients private key and senders public key can decrypt it.

DSA is based on a discrete logarithmic problem. RSA is based on the difficulty in the factorization of large integers.

RSA is far more common and commercially accepted. While it is possible for DSA to be over 1024 bits, many applications limit it to this. As such 2048 RSA algorithms are widely accepted as the minimum security standard to be cryptographically secure.

Android SSL/TLS

The javax.net.ssl packages provide all the necessary classes and interfaces required to program secure socket abstractions based on the SSL protocols SSLv3.0 / TLSv1.1.
All of the details of the SSL handshake protocol are accounted for and the client or a server can specify the cipher set to use. X.509 Certificates are verified and if desired, the client and server each have the option of verifying the entire certificate chain until the root Certificate Authority is reached.
Android uses code from the Legion of the Bouncy Castle and OpenSSL.

Defence in Depth

Defence in depth is a security and information assurance concept in which multiple layers of security controls are placed throughout an IT system. Its intent is to provide redundancy should the event of a security control fail or a vulnerability is exploited. So should a system fail or the bad guy managed to defeat it, there would still be a variety of fallbacks to protect the network. Firewalls for homes are not as popular as they used to be due to the increase use of home routers which act as a hardware firewall for all inbound connects unless outbound traffic to that destination has preceded it.

Defence in depth measures should not only prevent security breaches but also buy an organisation time to detect and respond to an attack, thereby reducing and mitigating the consequences of attack.

VPN Basics

a Virtual Private Network is a technology that provides secure communication through an insecure and untrusted network (like the internet). It achieves this through authentication, encryption, compression and tunneling.

What is tunneling?

Tunneling is a technique that encapsulates packet headers and data within the payload of another protocol. This way the packet can traverse the network in a manor it would otherwise not be capable of traversing.

How is it done?

The most common ways of creating a VPN are IPsec and SSL/TLS.

IPsec

IPsec provides authentication,encryption and compression at the network level. IPsec is actually a suite of protocols developed in the mid 90's and supports both IPv4 and IPv6. However it is mandatory in IPv6 and optional in IPv4. To implement IPsec two new protocols were added: Authentication Header (AH) and Encapsulating Security Payload (ESP). Handshaking and exchanging session keys are done using the the Internet Key Exchange (IKE) protocol.
The Authentication Header is protocol number 51 and it authenticates both the header and the payload. The AH however does not use encryption so it is almost never used.
Encapsulating Security Payload is protocol number 50. It enables you to add a security policy to the packet and optionally encrypt it. The encryption is done in the kernlet via the cryptoAPI. When two machines are connected via the ESP protocol, a unique number identifies the connection. This number is called the SPI (Security Parameter Index). Each packet contains a sequence number and a checksum which is called the ICV (Integrity Check Value). The checksum is calculated using a secret key which is known only to these two machines.

IPsec has two modes: Transport and Tunneling. When creating a VPN, we use tunnel mode. This means that each IP packet is fully encapsulated in the new IPsec packet. The payload of this new packet is the original packet before it was encapsulated.

The problem with this model is that in networks where the peer is behind a NAT (Network Address Translation) device. Using a NAT is a common way of connecting machines that are not directly accessable to the outside world. The NAT is performed on a machine that does have access, this is usually a gateway. The NAT modifies the IP packet and as a result the peer rejects it because the signature is wrong. The solution is commonly known as NAT-T (Network Address Translation Traversal) and works by encapsulating the IPsec packet in UDP packets so that they'll be able to pass through the NAT routers without being dropped.

OpenSwan is an open-source project that provides an implementation of IPsec. The SWAN name comes from Secure Wide Area Network which is actually a trademark of RSA. OpenSwan supports Opportunistic Encryption (OE), which enables the creation of IPsec based VPNs by advertising and fetching public keys from a DNS server.

SSL/TLS

OpenVPN is a VPN solution based on SSL/TLS. It is simpler in comparision with IPsec and OpenVPN supports RSA authentication, Diffie-Hellman key agreement, integrity checks etc. When running in server mode, it can support up to 128 clients over the same port. You can setup your own Certificate Authority and generate certificates and keys for an OpenVPN server and multiple clients.

OpenVPN operates in user-space mode; this makes it easy to port to other operating systems.

Overview of the SSL or TLS handshake

Secure Sockets Layer and its successor Transport Layer Security are cryptographic protocols that provide security over the internet.

They encrypt the segments of network connections at the Application Layer for the Transport Layer using Asymmetric Encryption for key exchange and Symmetric Encryption for confidentially and integrity.

Most protocols can be used in conjunction with TLS. Often this is done by specifying a different port, 443 for HTTPS. Another way of achieving the TLS connection is by the client requesting that the server switch to TLS. This is usually done by a protocol specific mechanism.

Once an agreement between A and B has been made to use TLS, a stateful connection is established by using a handshake procedure. During this handshake various parameters are passed between each other to establish the connections security.

1. The client sends the server the clients SSL version number, cipher settings and other details it needs to establish a connection
2. The server does the same back however it also sends it's own certificate (The certificate contains the servers public key) and if the client is asking for a resource that requires authentication, the server asks for the clients certificate
3. The client uses what it has been provided to authenticate the server. If the server can't be authenticated then the user is warned that the secure encryption connection can not be established.
4. Using all the data generated in the handshake thus far, the client creates the pre-master secret for the session and encrypts it with the servers public key. It sends the encrypted pre-master secret to the server
5. If the server has requested client authentication, the server attempts to authenticate the client. If the client can not be authenticated the session ends. If the client can be authenticated, it uses its private key to decrypt the pre-master secret.

Both client and server have now established that they trust who each other is and are both aware of the pre-master secret. With this they both perform a series of steps to establish the master secret.

Both parties now use the master secret to generate session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity.

The client now sends the server a message to state that future messages will be encrypted with the session key along with an encrypted message to state that it has finished it's own portion of the handshake.

The server performs the same action.

Now that the connection is established, the data shared between them is encrypted and decrypted. It's worth noting that at any time either side may renegotiate the connection and the whole process is repeated.

Applications

In application design, TLS is usually implemented on top of the transport layer protocols. Encapsulating the application specific protocols such as HTTP, FTP, SMTP, NNTP and XMPP.
TLS has also been implemented on datagram oriented transport protocols such as UDP (User Datagram Protocol) and DCCP (Data Congestion Control Protocol). This usage has been standardised as DTLS (Datagram Transport Layer Security).

TLS can also be used to tunnel an entire network stack to create a VPN (Virtual Private Network), as is the case with OpenVPN.
TLS is also a standard method to protect SIP (Session Initiation Protocol) application signaling. TLS can be used to provide authentication and encryption of the SIP signaling associated with VoIP and other SIP based applications.

Related Resources

• SSL Tutorial
• OWASP Transport Layer Protection Cheat Sheet
• Layman Guide to SSL/TLS
• CISCO foundation of web security

Related Wikipedia Reading

• Multiplexed Transport Layer Security
• Server gated cryptography
• tcpcrypt
• cryptlib
• JSSE
• PolarSSL

TCP/IP

I'll try to get down some of the main points of TCP/IP here.
Transmission Control Protocol / Internet Protocol is a stack of protocols defined for networking and exchange of data between computers. While the suite isn't limited to TCP, it's so common that that's how it's known.

The reason I referred to the suite as a stack is because they have a layered structure with each layer looking after certain aspects of data transfer. The entire stack can be broken down to:

1. Link Layer (Hardware / Ethernet)
Protocols Include:

• ARP
• RARP
• PPP
• Ether
2. Network Layer (The Invisible layer)
Protocols Include:

• IP
• ICMP
3. Transport Layer
Protocols Include:

• UDP
• TCP
4. Application Layer (The Visible Layer)
Protocols Include:

• Actual running applications. FTP client, browser etc
5. Physical Layer (Not part of TCP/IP)
Protocols Include:

• Telephone line

The stack has an almost cyclic attribute about it. Data travels from the Link Layer to the Physical Layer at the source and gets picked up at the Link Layer at the destination. Once there, each layer can hand off to the next.

There is obviously a lot more going on here and to understand the next point we need to delve into issues than can occur during data transfer using this model. The main problem is that the following two scenario's are likely to happen.

• Data Corruption
• Data Loss

Data Corruption

So data corruption is where the data arrived at the destination but it isn't what we sent. This can happen for a number of reasons but as an example, lets say the telephone line the message is sent from isn't very well shielded from interference.

Data Loss

Our data didn't even arrive - we don't need to know where it went, just that we didn't get it.

Overcoming these issues

So the solutions to these problems is actually quite easy. For the first issue of corruption, a simple checksum can be used to validate the content. For the second issue of data loss, sequencing numbers are used to order the packets. This makes it easy to see when we are missing data.

Checksum

So what is the checksum? This is (typically) a 16 bit value of the sum of all the octets in the datagram.

Sequencing

Because both of our issues are common, data is split into small packets and each is sent individually. This allows for a lot of flexibility in our error handling. These packets of data are not guaranteed to arrive in the order they were sent. To assist with realising if piece 4 has arrived after piece 5, a sequence number is used for each packet. This allows the receiver to order their packets in the order they were intended to be.

There is another way of detecting data corruption:

Handshaking

Handshaking is a series of messages that are sent back and forth. This takes the form of a SYN, SYN-ACK and ACK messages. Which are synchronise, synchronise acknowledgement and acknowledgement respecting. To put this down to basics, message 2 won't send until we get a message 1 acknowledgement. If the acknowledgement isn't received then a time-out occurs and message 1 would be resent.
So, what if message 1 was received but it was corrupted and didn't pass the checksum? The integrity would still be maintained if that packet was just discarded and the time-out waited for, but that is terribly inefficient. Instead a NACK message is sent instead of an ACK message.
An ACK message of 1000 would mean that all data up to octet 1000 had been received thus far.
So let's take an example of sending an email and use the knowledge we've just learned. Email's are most commonly sent over a protocol known as SMTP or Simple Mail Transfer Protocol. This protocol lives on the application layer. Say we have a SMTP server sitting somewhere that we need to pass our email on to. For the application to send this message it needs to pass its data the TCP protocol which belongs to the transport layer. This then needs to pass over to the IP protocol on the network layer which holds the checksum and sequencing features.

Three-way handshake

As part of the three way handshake, certain information is gained which gathers the information required to transmit with a minimum of problems. Information about the IP address, port number and datagram sizes are all collected at this point. Once the maximum datagram size is known the transmission can be split up. Each datagram has its own TCP header and includes the source and destination port, sequence number and checksum. TCP itself supports full duplexing, which means that data can go both upstream and downstream at the same time.

TCP supports a number of flags, we've already seen SYN, SYN-ACK and ACK. There is also:

• RST - Reset
• PSH - Tells the application to pass all queued data
• FIN - closes the connection

User Datagram Protocol

UDP is a member of the transport layer mentioned at the start. It is quite a different beast to TCP however and serves very different uses. Sometimes a datagram doesn't actual need to be split up and a single one will do just fine. UDP doesn't follow the same pattern of TCP, there's no synchronisation involved or sequence numbers and there doesn't even need to be any acknowledgement from the destination. Broadcasting is also possible with UDP.