Virtual HSM - Revision history

Kirill Krinkin at 18:24, 27 April 2014

2014-04-27T18:24:11Z

Kirill Krinkin at 13:45, 27 April 2014

2014-04-27T13:45:09Z

Kirill Krinkin at 19:41, 5 April 2014

2014-04-05T19:41:14Z

Show changes

Kirill Krinkin at 01:20, 3 March 2014

2014-03-03T01:20:03Z

Kirill Krinkin: Created page with "TBD"

2014-03-02T17:07:56Z

Created page with "TBD"

New page

TBD

@@ Line 170: / Line 170: @@
 * VHSM VE: <tt>vhsm</tt>
 * Client VE: <tt>libvhsmapi.a, vhsm_admin</tt>
-* Host: <tt>vhsm_transport.ko, vhsm_admin</tt>
+* Host: <tt>vhsm_transport.ko, vhsm_admin, vhsm_config</tt>
 == Usage ==
 To run VHSM perform the following steps:
-# Insert transport module: <code>insmod vhsm_transport.ko vhsm_veid=[veid]</code> where <code>[veid]</code> is VEID of the VHSM container
+# Insert transport module: <code>insmod vhsm_transport.ko vhsm_veid=[veid]</code> where <code>[veid]</code> is VEID of the VHSM container. '''OR''' Use <tt>vhsm_config</tt> to configure VHSM
 # Start VHSM in the VHSM container: <code>vhsm /path/to/storage</code>. You can init secure storage and create <tt>root</tt>-user on the first run
 # Add VHSM users from host: <code>vhsm_admin user create <admin login> <admin password> [options...]</code>. Run <code>vhsm_admin help</code> for details.
 # Now you can use VHSM from client VEs

@@ Line 14: / Line 14: @@
 === VHSM virtual environment ===
 [[File:VHSM_data_encryption.png|thumb|right|400px|Fig. 2 — Data encryption in the VHSM]]
-The VHSM VE contains the secure storage which is the database that stores the sensitive data in the encrypted form while other data (refer the table below) are stored unencrypted. The encryption key (master key) is generated from the user password using [http://en.wikipedia.org/wiki/PBKDF2 PBKDF2] and not stored in database. Utilizing PBKDF2 reduces the brute-force attack rate significantly if the database is compromised. The following table lists data that stored in the VHSM:
+The VHSM VE contains the secure storage which is the database that stores the sensitive data in the encrypted form while other data (refer the table below) are stored unencrypted. The encryption key (master key) is derived from the user password using [http://en.wikipedia.org/wiki/PBKDF2 PBKDF2] and not stored in database. Utilizing PBKDF2 reduces the brute-force attack rate significantly if the database is compromised. The following table lists data that stored in the VHSM:
 {|class="standard" border="1"
   !Data
@@ Line 78: / Line 78: @@
 The GCM mode guarantees integrity and confidentiality of the user data and therefore makes it possible to authenticate the encryption key derived from the user password. The VHSM uses this feature for user authentication. Registration process is shown in the [[Media:Vshm_user_registration.png|Fig. 3]].
-A user is authenticated ([[Media:Vhsm_user_auth.png|Fig. 4]]) using the login/password pair and the container ID (VEID) where authentication request is received from. When a user is registered it's bound to the set of containers where one can get access to the VHSM from. If the user attempts to access to the VHSM from a non-authorized container the request is refused.
+A user is authenticated ([[Media:Vhsm_user_auth.png|Fig. 4]]) using the login/password pair and the container ID (VEID) where authentication request is received from. When a user is registered it's bound to the set of containers authorised to access VHSM API. If the user attempts to access to the VHSM from a non-authorized container the request is refused.
 === Transport ===

← Older revision		Revision as of 01:20, 3 March 2014
Line 1:		Line 1:
−	~~TBD~~	+	'''Virtual HSM (VHSM)''' is a software suite for storing and manipulating secret data outside the virtualized application environment. While [http://en.wikipedia.org/wiki/Hardware_security_module HSM] is a physical device connected to the computer, this software provides HSM functionality in virtual environment based on OpenVZ container technology.
		+
		+	== Structure ==
		+	The project consists of the following key components:
		+	;VHSM virtual environment
		+	:VHSM VE is the isolated environment that contains the VHSM server and secure storage. The server performs operations on secret data and storage keeps encrypted user data
		+	;Transport layer
		+	:transport exchanges data between client and server virtual environments; based on [http://en.wikipedia.org/wiki/Netlink Netlink]
		+	;Client virtual environment
		+	:client API and accompanying utilities for accessing the VHSM server from a client environment
		+
		+	== Details ==
		+	=== VHSM virtual environment ===
		+	The VHSM VE contains the secure storage which is the database that stores the sensitive data in the encrypted form while other data (import date, purpose, etc) are stored unencrypted. The encryption key (master key) is generated from the user password using [http://en.wikipedia.org/wiki/PBKDF2 PBKDF2], and the salt that is used in the function is stored unencrypted in database. Thereby the VHSM doesn't keep the encryption key and utilizing PBKDF2 reduces the brute-force attack rate significantly if the database is compromised.
		+	The VHSM server is responsible for user authentication, interaction with the secure storage, and performing cryptographic operations.
		+	A client must be registered in the system to work with VHSM, so it reports its credentials to the VHSM admin. When the client is registered in the system a 256-bit authentication key is generated and encrypted in [http://en.wikipedia.org/wiki/Galois/Counter_Mode GCM mode] using the master key. The GCM mode guarantees integrity and confidentiality of the user data and therefore makes it possible to authenticate the encryption key derived from the user password. The VHSM uses this feature for user authentication.
		+	A user is authenticated using the login/password pair and the container ID (VEID) where authentication request is received from. When a user is registered it's bound to the set of containers where one can get access to the VHSM from. If the user attempts to access to the VHSM from a non-authorized container the request is refused.
		+
		+	=== Transport ===
		+	The data exchanging protocol between clients and the VHSM is written in the [https://code.google.com/p/protobuf/ Protocol Buffers] language. On the one hand, it allows to easily extend the protocol, on the other it's more space efficient compared to XML. In general, a protocol message contains parameters of the API function being called and some service information as well.
		+	As mentioned above, inter-container communication is based on Netlink, so the OS kernel contains the module that passes messages between virtual environments while VEs contain the transport API library which interacts with this module via Netlink sockets.
		+	The kernel module identifies containers by their VEIDs that are provided by OpenVZ. The VHSM environment ID is passed as a parameter to the module. Messages from other containers are routed to that VEID. The passed message contains serialized protobuf data and the header with the message type, container VEID and process PID. Meaning of these parameters depends on the transfer direction. If the message comes from a client container then the module checks its VEID and forwards the message to the VHSM VE if the container is allowed to send requests to the VHSM. When the kernel module forwards the message it sets the VEID in the message header to the sender VEID and the PID to the sender process PID derived from the Netlink message header. So the VHSM can address the response to the client. If the message is transferred from the VHSM then the VEID and PID in the message header are set by the VHSM itself. It's possible because the VHSM sends responses to the client requests only and never initiates communication with a client.
		+
		+	=== Client virtual environment ===
		+	The client part of the VHSM consists from the API-library and some auxiliary tools (such as [http://www.openssl.org/docs/crypto/engine.html OpenSSL engines]).
		+	The VHSM API library provides PKCS#11-like functions for managing sessions and user keys and for digital signing.
		+	Client applications may directly call library functions or may use OpenSSL extensions. The VHSM API allows the user to import or generate some secret data (keys). These data is encrypted by AES-GCM algorithm using the user master key and then stored in the database. Then the user gets the data id which allows to use these data in the future.
		+	If the user wants to perform a cryptographic operation then one tells key id for this operation to the VHSM. The VHSM extracts the key from the storage, decrypts it and performs computations in its isolated virtual environment while the user gets the result of the operation only.
		+	OpenSSL can act as a layer between a client application and the VHSM API library. To achieve that OpenSSL engines can be used. Engines extend the functionality of the OpenSSL and allow to override implementation of some cryptographic algorithms. For example, OpenSSL engines make it possible to use a physical cryptographic device without modifying the code of the client program.
		+
		+	== Building ==
		+
		+	Install the following packages to build the project on your system. On CentOS use [http://fedoraproject.org/wiki/EPEL/FAQ#How_can_I_install_the_packages_from_the_EPEL_software_repository.3F EPEL repositories]
		+
		+	{\| class="standard" border="1"
		+	!Package
		+	!Debian
		+	!CentOS
		+	\|-
		+	\|CMake 2.8
		+	\|cmake
		+	\|cmake28
		+	\|-
		+	\|OpenVZ kernel headers
		+	\|linux-headers-2.6.32-5-openvz
		+	\|vzkernel-headers
		+	\|-
		+	\|Google protobuf compiler
		+	\|protobuf-compiler
		+	\|protobuf-compiler
		+	\|-
		+	\|libprotobuf
		+	\|libprotobuf-dev
		+	\|protobuf-devel
		+	\|-
		+	\|crypto++ 5.6.2
		+	\|libcrypto++-dev
		+	\|cryptopp-devel
		+	\|-
		+	\|SQLite 3
		+	\|libsqlite3-dev
		+	\|sqlite-devel
		+	\|-
		+	\|cppunit ''(optional)''
		+	\|libcppunit-dev
		+	\|cppunit-devel
		+	\|}
		+
		+	To build the project just run <code>cmake</code> and then <code>make</code>. You may build binary packages with the command <code>make pkg</code>.
		+
		+	== Installation ==
		+
		+	You may use binary packages or install manually:
		+	* VHSM VE: <tt>vhsm, vhsm_admin</tt>
		+	* Client VE: <tt>libvhsmapi.so, vhsm_user_admin</tt>
		+	* Host: <tt>vhsm_transport.ko</tt>
		+
		+	== Usage ==
		+
		+	To run VHSM perform the following steps:
		+	# insert transport module: <code>insmod vhsm_transport.ko vhsm_veid=%veid%</code> where %veid% is VEID of the VHSM container
		+	# create secure storage in the VHSM VE: <code>vhsm_admin i /path/to/storage</code>
		+	# add VHSM user: <code>vhsm_admin c /path/to/storage login password</code>
		+	# start VHSM in the VHSM container. You can specify the path to the secure storage in program arguments
		+	# run <code>vhsm_user_admin</code> from client VE