# SignCloud Security Model

## 1. Sole Control Objective

The core security objective is ensuring that only the Virtual Token owner can activate and use the private key.

This is achieved through:

- Key splitting
- PIN-derived cryptographic material
- HSM-bound operations
- Strict error counter enforcement


## 2. Password and PIN Derivation

AES-256 keys are derived from passwords using:

PBKDF2 (HMAC-SHA1, 4096 iterations)

PIN constraints:

- Min 8 characters
- ASCII range 32–126
- ≥ 2 numeric characters
- ≥ 2 alphabetic characters
- ≥ 5 distinct characters
- Minimum entropy constraints


## 3. Application Key (K_WAPP)

K_WAPP:

- Allows export of non-user-consent cryptographic material
- Stored encrypted in DB
- Protected by HSM operator smartcard
- Requires operator PIN after restart


If smartcard removed → operations disabled.

## 4. Virtual Token Activation (Detailed Cryptographic Flow)

At the creation each Virtual Token is Disabled; in this state any operation that could be performed by the
user, including access, is inhibited.
During the first activation, the end-user sets PIN (TokenPIN) and PUK (TokenPUK) codes for his/her Virtual
Token, enabling it to be used. The two values, TokenPIN and TokenPUK, are used in the HSM for the key-pair
generation and for signing/deciphering processes; they are never stored inside SignCloud, but only
cryptographically verified during each operation within the HSM. It means that if the codes provided by the
user are wrong, the HSM won’t be able to use the keys belonging to the users.

1. The user accesses the SignCloud server, using First Emission application with the provided credentials
TokenID and TokenPassword, requesting the first activation of the Virtual Token.
2. SignCloud verifies that the Virtual Token doesn’t already have a TokenPIN and TokenPUK, otherwise it shows an error message to the user, because the token could have been compromised by someone
else.
3. The app requests to choose the secret codes [PIN and PUK] (asking to type both of them twice to avoid errors).
4. The app sends the data to the server using a secure HTTPS connection.
5. The SignCloud server checks that the codes are compliant with the security policies in place on the system. If the checks are successful the activation continues, otherwise an error message is sent back to the user.
6. SignCloud generates a casual AES-256 key for the Virtual Token inside the HSM (𝐾vt0). This key is only usable as part of a logic XOR with another key or exported by wrapping it using the SignCloud server key 𝐾wapp


Access Control List 𝐾vt0
1. SignCloud creates an AES-256 key from the TokenPIN and imports it in the HSM module (𝐾vt1). This key is created as not-exportable and is only usable as part of a logic XOR with another key.


Access Control List 𝐾vt1
1. SignCloud creates an AES-256 key (𝐾wvt) from a logic XOR between the keys 𝐾vt0 and 𝐾vt1. This key is created as not-exportable and is usable to wrap other keys or as part of a logic XOR with another key.


Access Control List 𝐾wvt
1. SignCloud creates an AES-256 key from the TokenPUK and imports it in the HSM module (𝐾vt2). This key is created as not-exportable and is only usable as part of a logic XOR with another key.


Access Control List 𝐾vt2
1. SignCloud creates an AES-256 key (𝐾vtr) from a logic XOR between the keys 𝐾wvt and 𝐾vt2. This key is only usable as part of a logic XOR with another key or exported by wrapping it using the SignCloud servers 𝐾app.


Access Control List 𝐾vtr
1. The key 𝐾vt0 is protected using 𝐾app and saved in the DB in the record related to the Virtual Token
2. The hash of the 𝐾wvt key (ℎkwvt) is saved in the DB in the record related to the Virtual Token in use.


## 5. RSA Key Pair Generation Flow

1. The user accesses the SignCloud server using the UKC (Universal Key Chain) application with the provided credentials TokenID and TokenPassword.
2. The user, using an enrolment software, requests the creation of a key-pair to the UKC cryptographic module.
3. The software requests the TokenPIN to the user.
4. The software requests to the UKC cryptographic module (which exposes the standard interfaces PKCS#11 and CSP) to generate an RSA key-pair for a Virtual Token attaching the TokenPIN and additional info about the needed key.
5. The UKC sends the collected data to the SignCloud server using a secure HTTPS connection.
6. SignCloud verifies the credentials (TokenID, TokenPassowrd) and, only if they are correct, it proceeds to the following steps. In case the credentials are wrong, it sends an error message to the user. After 3 errors in a row, the system won’t accept any other request for 5 minutes. This interval is increased every time, up to a maximum of 1 hour for each error.
7. SignCloud checks that the errors counter is greater than zero. In case it is equal or lower than 0, the virtual token is blocked and a notification will be sent to the user.
8. SignCloud retrieves the key 𝐾vt0, which was associated to the virtual token and protected with the key 𝐾wapp, from the DB and imports it in the HSM.
9. SignCloud creates an AES-256 key from the TokenPIN and imports it in the HSM module (𝐾vt1).
10. SignCloud creates an AES-256 key (𝐾wvt) from a logic XOR between the keys 𝐾vt0 and 𝐾vt1.
11. SignCloud checks that the hash of the key 𝐾wvt is equal to the ℎkwvt stored in the DB in the record related to the Virtual Token in use. If it doesn’t match, SignCloud decrements the PIN errors counter and produces an error message.
12. SignCloud creates an RSA key for the Virtual Token in the HSM module (𝐾rsa). The public component of the RSA key is exported in clear from the HSM, while the private component is wrapped using the key kwvt.


Access Control List 𝐾rsa
1. The wrapped RSA key is saved in the DB, in the record related to the Virtual Token


## 6. Private Key Usage Flow

1. The user accesses the SignCloud server using the UKC with the provided credentials TokenID and TokenPassword.
2. The user, using a software for the digital signature, requests the usage of the private key for a signing operation.
3. The software requests the TokenPIN to the user.
4. The software sends a request to the UKC cryptographic module (which exposes the standard interfaces PKCS#11 and CSP) to apply the private RSA key of the Virtual Token to a buffer, which is attached to the request together with the TokenPIN.
5. The UKC sends the collected data to the SignCloud server using a secure HTTPS connection.
6. SignCloud verifies the credentials (TokenID, TokenPassowrd) and, only if they are correct, it proceeds to the following steps. In case the credentials are wrong, it sends an error message to the user. After 3 errors in a row, the system won’t accept any other request for 5 minutes. This interval is increased every time, up to a maximum of 1 hour for each error.
7. SignCloud checks that the errors counter is greater than zero. In case it is equal or lower than 0, the virtual token is blocked and a notification will be sent to the user.
8. SignCloud retrieves the key 𝐾vt0, which was associated to the virtual token and protected with the key K-wapp, from the DB and imports it in the HSM.
9. SignCloud creates an AES-256 key from the TokenPIN and imports it in the HSM module (𝐾vt1).
10. SignCloud creates an AES-256 key (𝐾wvt) from a logic XOR between the keys 𝐾vt0 and 𝐾vt1.
11. SignCloud checks that the hash of the key 𝐾wvt is equal to the ℎ𝐾wvt stored in the DB, in the record related to the Virtual Token in use. If it doesn’t match, SignCloud decrements the PIN errors counter and produces an error message.
12. SignCloud retrieves from the DB the key 𝐾rsa associated to the virtual token and protected with 𝐾wvt, and imports it in the HSM.
13. SignCloud signs the provided buffer with the private key 𝐾rsa.


## 7. Signature Process Models

### Full Document Model

- Entire document sent to SignCloud.
- Server computes hash.
- Hash signed.
- Hash compared with document.
- Integrity guaranteed server-side.


### Hash-only Model

- SCA computes document hash.
- Hash sent to SignCloud.
- Signed hash returned.
- Integrity guaranteed by SCA.


## 8. PIN and PUK Replacement Flows

### PIN Replacement (Old PIN Known)

1. The user accesses the SignCloud server using the UKC with the provided credentials TokenID and
TokenPassword.
2. The user, by the mean of the UKC, requests to start a PIN replacement operation.
3. The UKC requests to the user to insert the old PIN (TokenOldPin) and the new PIN (TokenNewPin, asking to type the latter twice to avoid errors).
4. The 2 PIN codes are sent to the SignCloud server using a secure HTTPS connection.
5. SignCloud verifies the credentials (TokenID, TokenPassowrd) and, only if they are correct, it proceeds
to the following steps. In case the credentials are wrong, it sends an error message to the user. After 3 errors in a row, the system won’t accept any other request for 5 minutes. This interval is increased every time, up to a maximum of 1 hour for each error.
6. SignCloud checks that the errors counter is greater than zero. In case it is equal or lower than 0, the virtual token is blocked and a notification will be sent to the user.
7. SignCloud retrieves the key 𝐾vt0, which was associated to the virtual token and protected with the key 𝐾wapp, from the DB and imports it in the HSM.
8. SignCloud creates an AES-256 key from the TokenOldPin and imports it in the HSM module (𝐾vt1).
9. SignCloud creates an AES-256 key (𝐾wvt) from a logic XOR between the keys 𝐾vt0 and 𝐾vt1.
10. SignCloud checks that the hash of the key 𝐾wvt is equal to the ℎ𝐾wvt stored in the DB, in the record related to the Virtual Token in use. If it doesn’t match, SignCloud decrements the PIN errors counter and produces an error message.
11. SignCloud creates an AES-256 key from the TokenNewPin and imports it in the HSM module (𝐾vtn1).
12. SignCloud creates an AES-256 key (𝐾vtn0) from a logic XOR between the keys 𝐾wvt and 𝐾vtn1.
13. The key 𝐾vtn0, wrapped using 𝐾wapp, is saved in the DB in the record relative to the Virtual Token in use, replacing the old 𝐾vt0.


### PUK Replacement

1. The user accesses the SignCloud server using the UKC with the provided credentials TokenID and TokenPassword.
2. The user, by the mean of the UKC, requests to start a PUK replacement operation.
3. The UKC requests to the user to insert the old PUK (TokenOldPuk) and the new PUK (TokenNewPuk, asking to type the latter twice to avoid errors).
4. The 2 PUK codes are sent to the SignCloud server using a secure HTTPS connection.
5. SignCloud verifies the credentials (TokenID, TokenPassowrd) and, only if they are correct, it proceeds to the following step. In case the credentials are wrong, it sends an error message to the user. After 3 errors in a row, the system won’t accept any other request for 5 minutes. This interval is increased every time, up to a maximum of 1 hour for each error.
6. SignCloud checks that the PUK code errors counter is greater than zero. In case it is equal or lower than 0, the virtual token is blocked and a notification will be sent to the user.
7. SignCloud retrieves the key 𝐾vtr, which was associated to the virtual token and protected with the key 𝐾wapp, from the DB and imports it in the HSM.
8. SignCloud creates an AES-256 key from the TokenOldPuk and imports it in the HSM module (𝐾vt2).
9. SignCloud creates an AES-256 key (𝐾wvt) from a logic XOR between the keys 𝐾vtr and 𝐾vt2.
10. SignCloud checks that the hash of the key 𝐾wvt is equal to the ℎ𝐾wvt stored in the DB, in the record related to the Virtual Token in use. If it doesn’t match, SignCloud decrements the PUK errors counter and produces an error message.
11. SignCloud creates an AES-256 key from the TokenNewPuk and imports it in the HSM module (𝐾vtn2).
12. SignCloud creates an AES-256 key (𝐾vtrn) from a logic XOR between the keys 𝐾wvt and 𝐾vtn2.
13. The key 𝐾vtrn, wrapped using 𝐾wapp, is saved in the DB in the record relative to the Virtual Token in use, replacing the old 𝐾vtr.


### PIN Reset Using PUK

1. The user accesses the SignCloud server using the UKC with the provided credentials TokenID and TokenPassword.
2. The user, by the mean of the UKC, requests to start a PIN replacement operation.
3. The client-side application requests to the user to insert the PUK (TokenPuk) and the new PIN (TokenNewPin, asking to type the latter twice to avoid errors).
4. The 2 codes are sent to the SignCloud server using a secure HTTPS connection.
5. SignCloud verifies the credentials (TokenID, TokenPassowrd) and, only if they are correct, it proceeds to the following step. In case the credentials are wrong, it sends an error message to the user. After 3 errors in a row, the system won’t accept any other request for 5 minutes. This interval is increased every time, up to a maximum of 1 hour for each error.
6. SignCloud checks that the PUK code errors counter is greater than zero. In case it is equal or lower than 0, the virtual token is blocked and a notification will be sent to the user.
7. SignCloud retrieves the key 𝐾vtr, which was associated to the virtual token and protected with the key 𝐾wapp, from the DB and imports it in the HSM.
8. SignCloud creates an AES-256 key from the TokenOldPuk and imports it in the HSM module (𝐾vt2).
9. SignCloud creates an AES-256 key (𝐾wvt) from a logic XOR between the keys 𝐾vtr and 𝐾vt2.
10. SignCloud checks that the hash of the key 𝐾wvt is equal to the ℎ𝐾wvt stored in the DB in the record related to the Virtual Token in use. If it doesn’t match, SignCloud decrements the PUK errors counter and produces an error message.
11. SignCloud creates an AES-256 key from the TokenNewPin and imports it in the HSM module (𝐾vtn1).
12. SignCloud creates an AES-256 key (𝐾vtn0) from a logic XOR between the keys 𝐾wvt and 𝐾vtn1.
13. The key 𝐾vtn0, wrapped using 𝐾wapp, is saved in the DB in the record relative to the Virtual Token in use, replacing the old 𝐾vt0.


## 9. Error Counters

Separate counters for:

- PIN errors
- PUK errors


If counter ≤ 0:

- Virtual Token blocked
- User notified


## 10. Threat Analysis

Several attack scenarios have been considered during the design of the SignCloud system, especially during the definition of the mechanisms used to ensure the sole control of the Virtual Token to its owner. In general, cyber-attacks can be classified as internal or external attacks.

### External Attacks

External threats originate from outside the organization, primarily from the environment in which the organization operates. This type of attacks aims to get an unauthorized access to user keys for external attackers, not belonging to the administrative structure managing the CA.

- Dictionary attack on the users’ virtual token secret codes
- Brute-force attack on the users’ virtual token secret codes


The platform is perfectly able to handle both these types of attack. To avoid automatic submission of credentials, the system doesn’t’ accept further requests for an increasing amount of time after a certain number of failed tries.

### Internal Attacks

Internal threats originate from within the organization. The attacks coming from internal employees (e.g. system admin), aiming to get an unauthorized access to user keys, fall under this category.

- Stealing information from the DB and trying to use it to discover users’ keys value or secret codes.


SignCloud is resistant to these threats, the platform stores only non-sensitive information in the DB and the data must be integrated with users’ PIN/PUK to unlock the usage of the private keys.

- Direct Dictionary or Brute-force attack on users’ PIN/PUK codes


An attacker could try to unveil users’ PIN or PUK codes using a brute force attack on the entire PIN domain.
This attack would require trying all the feasible values for a PIN, executing the logical operation to create the keys 𝐾!$%, hashing the generated values and comparing them with the values stored in the DB. The check on the number of failed tries couldn’t be performed, because it is part of the application layer. In this more dangerous scenario, the attacker could be able to perform all the tries directly on the HSM.

Considering that:

- The system has strict rules for the definition or replacement of PIN/PUK codes. The policies imposed
for the codes define an interval allowing about 6.6*10', different values.
- For each code the attacker has to perform the following operation:
𝑋𝑂𝑅 (𝐾wvt0, 𝑃𝐵𝐾𝐷𝐹2(𝐶𝑂𝐷𝐸, 𝑖 = 4096))
- The operation must be executed on one of the HSMs in the PROD environment, because the key 𝐾wvt0 is protected by using both the key 𝐾!"## and the operator smartcard
- Obtaining the PBKDF2 of a key with 4096 iterations is a highly parallelizable operation and there are several optimizations using the GPU to speed-up the computational process. For these reasons, the bottleneck in the infrastructure would be the HSM.
- The operations on the HSM can be parallelized using the entire SignCloud cluster.


Given the preconditions mentioned above, it has been verified that a single HSM, with the highest grade of parallelism and multiplied for a security factor, can perform up to 10000 operations per second. As additional security term during the stress tests, it has been reduced the key space by half. Based on these parameters,
it has been possible calculating the estimation of a successful attack duration:

Attack Duration Estimate
Based on the obtained results, a feasible scenario considering very high performance, a disaster recovery site and a cluster including between 2 and 5 servers per site would require an impressive amount of time to compromise the system, making the attack unfeasible.