Description

The architecture of the HSM Dinamo is based on principles of modularity, separation of key partitions, access control, protection against tampering, as well as optimization with the aim of offering stability and performance in cryptographic operations.

There are three basic items in the HSM architecture: users, objects and modules.

Users are the entities that request services and have a storage area within the HSM; these areas are also called user partitions. They are also the users who can open service sessions with the HSM. Each user corresponds to a partition in the HSM.

Objects are the entities stored within the HSM partitions. Every object is intrinsically related to a user. There is a special type of object, which is one that contains cryptographic material, usually a symmetric or asymmetric encryption key; these objects are called keys and have a higher level of protection and control than other objects. The other objects can be of various types, such as certificates or chains of digital certificates, lists of revoked certificates, or even an opaque object with no meaning for the HSM. Objects can also be temporary, which are non-persistent objects between sessions, i.e. they only exist during the session and are removed by the HSM at the end of the session. At Dinamo all objects are kept internally encrypted by a Server Master Key in the persistent memory area and are only decrypted when there is a valid access request and always to volatile memory.

Modules are the service-providing units within the HSM, each responsible for a specialty. Within the modules are the implementations of cryptographic or generic algorithms. There is a fairly rigid communication interface with each module, exposed to users via the APIs in the HSM function library. With the exception of the Core and State Manager modules, which provide basic services and serve other modules, all the modules are optional, meaning that the HSM can be configured in the factory according to the needs of each demand, optimizing costs and the use of resources.

Within HSM, each user has sovereignty over their partition, meaning they can create, change and remove their own objects. They can also give other users permission to access the objects in their partition. There are no users or administrators with implicit permission over other users' partitions; all permissions must be given explicitly by the user who owns the partition. There is no common or public storage area. The partition will exist as long as the user exists in the HSM database.