Traditionally organisations implemented their secure transaction systems in their own data centres where they had direct control of all the security components and the sensitive data being stored and processed. However problems of scalability, high availability and disaster recovery have put pressure on companies to move their transaction processing into the cloud. The question then is how do you keep control of security?
The typical data eco system involves 3 layers,
The authentication and secure channel requirements for access control to the data resources is addressed in a separate paper but it is noted here that the cryptographic services consumed need to be provided as part of the particular eco system. The use of client certificates for example will need to be created as part of the overall cryptographic hierarchy and it is assumed that such key management services will be provided through the use of Hardware Security Modules (HSMs) and Secure Elements (SEs).
The secure storage of sensitive data implies cryptographic protection but it should be immediately appreciated that this requires elaboration to the protection of data confidentiality and data integrity. In addition in most cases it is also necessary to protect the data from unauthorised deletion and/or the replay of previously authorised data. It should be noted that these latter requirements are not directly solved by any cryptographic service but need the concepts of uniqueness and freshness such as sequence numbers which may however be protected by cryptographic services.
The secure storage of data is accordingly presumed to be provided by the application of cryptographic security services which should mean that the data is stored encrypted at the data base level if confidentiality is an issue but also with the application of cryptographic signatures or check sums. It is immediately obvious that if this protection is applied or removed outside of the HSM then the data is vulnerable. This is why encryption solutions that are applied at the data base level are in general not adequately secure.
What is really required is the application of cryptographic services at the application level because this will not only provide for the encryption of data but also allows the application of data integrity services. In addition at the application level it is then possible to protect the data from unauthorised deletion or replays.
Many current solutions to these problems try to apply solutions at the client level. For example if the data stored at the data base is protected by asymmetric cryptographic techniques then it would be possible for only the client to be able to decode the encrypted data. However this overlooks the fundamental definition of the data, who is responsible for the authenticity of the data? If the client creates the data and is the only consumer then it can work but immediately there are assumptions of sharing or processing of the data then you must employ a trusted entity. Such a trusted entity will need to use a Hardware Security Module (HSM) but what becomes clear is that it should not just be a source of cryptographic keys but should actually act as the end point that manages the encryption of stored data and also the point at which transactions involving the data are executed.
It is the purpose of this paper to show a hybrid cloud security solution where the application end point takes place within the HSM. It is further assumed that the HSMs are operated in a secure data centre under the control of the data manager while the transactions and data storage are provided at the cloud level such as that provided by Amazon AWS.
The STiC system provides a cloud system where the data transactions are executed within a secure end point as provided by an HSM. This means that the data never exists unprotected outside of the HSM. Consider for example a typical encrypted data base architecture,
The application applies encryption to the data when it is stored on the data base and decrypts the data when it is called back into memory. The application may use the HSM to provide the keys for the encryption, it may actually be used to actually do the encryption but in many cases the application doesn’t use an HSM at all. In all cases it is clear that the application is vulnerable to any attack relating to the use of the memory. The core security weakness is that the security end point is actually outside of any protected environment as could be provided by an HSM.
The STiC system by comparison moves the security end point into an HSM but in addition it moves the HSM into a secure data centre as defined by the data manager. There is a secure channel between the cloud environment and the data centre but more particularly the cryptography is executed within the HSM at the application level.
What this means is that the data cannot be effectively manipulated outside of the HSM without detection which makes it very difficult to attack for both internal and external hackers.
Although the data base is still encrypted the application is providing the encrypted data to the HSM which not only decrypts the data and checks the data integrity functions but also actually executes the transaction by modifying the data as necessary and then returning the encrypted modified data for updating the data base. The operation of the data base is atomic such that all the data is updated or none. This means the HSMs can operate in a stateless mode of operation which is fundamental for any disaster recovery strategy. Backing up HSMs that maintain state information is an enormous overhead in any transaction system.
There is a further advantage of this approach in that it protects the system from any form of abuse of the HSM at the key management application level. If the application is able to send direct crypto commands to the HSM then depending on how the key management is implemented it may be possible to dupe the HSM into providing secret keys. For example if the hacker can persuade the HSM to encrypt an unknown key with a key that the hacker knows.
The STiC system also allows the operators to manage multiple application end point scripts. These scripts can be stored on the encrypted data base and loaded into the HSMs as and when required. The end point script is of course created within the security domain of the HSM and is protected for both confidentiality and data integrity.