exploring software and hardware security

Before starting discussing different techniques which are helpful while creating architecture of a secure system, it’s useful to go through the key concepts which must always be at primary concern of any software/hardware architect while thinking about security.

In this article we will go through the key concepts in information security and will try to explain them by bringing real life examples. Throughout the article I will also call the key concepts “security properties” of information.

So the security properties we will discuss here are:

• Confidentiality
• Integrity
• Authenticity
• Availability
• Non-Repudiation
• Accessibility

Why is it so important to always remember about these properties? Sometimes engineers just forget about the real security properties they need to protect and create systems which have lots of overheads and implement unnecessary security controls in it by complicating the overall system and introducing security holes. This can be avoided if we think about security properties from the very beginning and don’t forget about them until the system architecture is ready.

In information security what you need to protect is a block of information. Nothing more… If you are going to protect, for example, your car – that’s not a problem of information security. It’s a problem of physical security or another similar discipline. So let’s remember: in information security whatever we design we need to focus on the information and its security properties. The rest is not important.

Any information block may have 6 different security properties:

• Confidentiality – a security property which allows hiding the content of information from eavesdroppers. Even if eavesdroppers have the digital information in hand, they cannot see the real content if its confidentiality is protected.
• Integrity – a security property which allows making sure that the block of information is not modified/corrupted.
• Authenticity – a security property which allows authenticating the sender of information.
• Availability – a security property which allows making sure that the block of information is available to everyone whoever needs it.
• Non-Repudiation – a legal property which allows making sure that the person (or a company) who performed some operation on a block of information cannot refuse his participation in this operation in the future.
• Accessibility – a security property which describes the access rights (like read-only, read-write, etc) of all components in the system for a block of information.

A block of information may have zero or multiple security properties. Its security properties may be completely disappeared during its lifetime or be transformed from one type of property to another.

While designing a security system the architect needs to design security controls which will make sure that the security properties of all the information blocks cannot be damaged during their lifetime. Once this is done – the architect can be sure that the system security architecture is complete.

So the main task of a security architect is to:

1. identify the blocks of information which have got security properties
2. identify exactly what security property each of these information block has
3. design security controls to protect the security properties of all information blocks that have been identified during the step #1

Note that the complete algorithm of how to design secure systems is described in my previous article – How to design secure systems? Security Analysis.

Let’s bring a simple example and discuss each of these properties using real life terms. Note that as we need to cover all the security properties in it – the example may be somewhat artificial.

Suppose we need to design a social network similar to facebook.com. Let’s call it soshial.net. The users register with that web service and communicate with each other through it. The users are also able to keep sensitive information, such as personal files on the server.

Let us list the original requirements of the system:

1. Each user must have access only to his/her account.
2. User can submit his/her personal information in his/her account.
3. User’s private files should not be accessible even to the web service administrator.
4. After a user A sends a message to user B, user A must not be able to refuse this operation in the future.

Now let us try to identify the information assets and security properties associated with them.

Information Block	Security Properties
User’s personal information	Authenticity – must be accessible only to the right user Accessibility – read/write for authenticated user, read-only for unauthenticated users
User’s private files	Confidentiality – this information shall be accessible only to the user (even not to the admin) Integrity – any modification must be detected Authenticity – must be accessible only to the right user Accessibility – read/write for authenticated user
Message from user A to user B	Non-Repudiation – after sending a message to user B, the user A shall not be able to refuse this operation in the future Authenticity – only authenticated users must be able to send messages form their names

Now let us design security controls to protect these properties.

First of all in order to protect the authenticity of user’s personal data we need to have a way to control the user authentication. We will use username/password approach to do that. So each user will create a username/password during registration and present this pair before getting access to his/her account.

After introducing username/password we have got new information blocks which also have security properties:

• Password
  • Confidentiality – only accessible to owner (even not to administrator)
• Let’s assume that username doesn’t have any security property in this example

Confidentiality, Integrity and Accessiblity

In order to protect the confidentiality of password, the server will store the hash (say SHA1) of password in its database. However we will also need to protect the confidentiality when the password is sent from user’s machine to the server. Here we will use HTTPS as a security control. HTTPS is based on SSL and it protects the confidentiality and integrity of data being sent over HTTP.

So, all the information that belongs to a user will be accessible only to that particular user. However user’s personal information will be accessible also to other users but only in read-only format.

After the user inputs his/her personal information during registration, this information becomes available to everyone in read-only mode. This goal will be achieved simply by having a script on the server which controls the accessibility of data and allows modifying data only to authorized people (in this example it’s the authenticated user).

In order to protect the confidentiality and integrity of user’s private files we will associate a symmetric key (say AES) with each user. This symmetric key will be used to encrypt all the files that belong to that user. Thus, these files will be stored on the server in encrypted form. In this case even the administrator cannot access them. The symmetric key, itself, will be created and immediately encrypted with user’s password when the user registers with the web service. So the key will be available only during the session when the user is logged in. Once user logs out – the key will be removed from server’s RAM. This mechanism allows protecting confidentiality of user’s private files.

However though confidentiality is protected, the integrity of data is still not there. If any file is modified – the user won’t see that modification unless he decrypts the file and looks inside. Even worse, if, for example, the last 16 bytes of an AES encrypted file is corrupted, the user might not notice that until he explicitly needs those 16 bytes, and if he needs them during a critical mission operation – this would be a huge problem.

So in order to protect the integrity of these files we can calculate a simple checksum (CRC32) or cryptographic hash (SHA1) and attached to the end of each file. Before loading the file we will verify the checksum and if the verification fails – will report to the user.

However still the authenticity of files is not there… What if someone modifies the entire file by purpose and attaches a valid checksum to the end of this file? User will decrypt the file and get some corrupted data but he won’t be able to verify the authenticity of data (to verify that he is the creator of that file). In order to solve this problem we will need to use message authentication code (MAC). In this particular example we will use HMAC-SHA1. So each time a user downloads a new file or modifies an existing one – the server will calculate a new HMAC-SHA1 based on the encryption key and file content and will attach it to the end of the file. When the user loads a file, the server script will verify the HMAC of data and make sure that this data has been created by this user and hasn’t been modified. Thus the authenticity and integrity properties are protected.

Authenticity and Non-Repudiation

Now the security properties of user’s personal information and user’s private files are protected.

The only security properties that are not protected yet are the authenticity and non-repudiation of messages. In order to protect the authenticity the server script just needs to allow sending messages only after the user logs in to his account and disallow to change the username field of the message.

However it’s little bit difficult with non-repudiation. Let me describe the problem. In case of non-repudiation the receiver of message must be able to verify that the sender is user A and user A cannot refuse that he created that message. In the same time no one but user A must be able to create that particular message otherwise user A would claim that someone else created that message and not him.

We can use PKI to solve the problem of non-repudiation. It will complicate the existing system significantly but the requirement itself is difficult. Each user will have a public and private keys assigned to them and the public part will be signed by a certification authority. When user A sends a message he will sign the message data with his private key. User B can verify the signature of message using user A’s certificate. With this approach nobody can create a valid message but user A and in the meantime after having a message created by user A, user B can always claim that user A has sent him that message and nobody else.

Availability

In our case social.net is a web service with millions of users and if this service stops working – it may have a huge business impact. There can be many technical reasons why this service might stop – technical problems, improper administration, DOS or other types of attacks…

In order to maintain the availability of social.net different security controls need to be designed, such as anti-DOS defense, database backup, etc.

This was just a demonstrative example which showed how engineers should think about security properties of the data they are trying to protect.