The digital signature is a scheme to validate the privacy of a conversation, integrity of data, and authenticity of the message or sender. In simple terms, a digital signature gives the receiver a reason to validate that the message was sent by the claimed sender. This property of digital signature is called non-repudiation. A digital signature works on the principle of two mutually authenticating cryptographic keys, i.e., a public key and a private key. A private key is a securely stored secret key that is only known by the user and is used to manage identity and security.
Public key infrastructure (PKI) and the need for digital signatures:
Public-key cryptography is vulnerable to a Man-in-the-middle attack where the attacker intercepts the connection between the sender and the receiver to use their key pair to encrypt and decrypt the messages, thus taking control over the connection. This type of key injection attack can be mitigated using digital certificates which validate the identity of the sender.
PKI is a set of policies used to manage cryptographic keys. It binds these keys to the entities such as persons, services, and organizations, through the issuance of digital certificates. The trusted third-party entity that provides this digital certificate is the certificate authority (CA). CA validates the entity’s identity and issues a signed digital certificate containing the public key and other information of the individual or organization. The CA’s signature on a certificate confirms that the public key and other information in the certificate belong to the claimed user. Any tampering with the contents of the certificate will be easily detected. This is because of the established certificate chain of trust. It consists of root certificates, intermediate certificates, and end-user certificates. Root CAs are a trusted source of certificates, intermediate CAs are bridges that link the end-user certificate to the root CA.
Digital signature algorithm in OPTIGA™ Trust M:
The digital signature assures that only the sender knows the private key which is used to sign the message. The message shared is passed through a hash algorithm and the generated hash is signed using the sender’s private key. The signed hash, along with other information like the hashing algorithm, is known as a digital signature.
The signature is generated using the CalcSign function in OPTIGA™ Trust M. The signature is calculated over the provided message digest. Using a hash function such as Secure Hashing Algorithm SHA-256 / SHA-384 / SHA-512 an intermediary representation of the data is produced and then the result of the hash (digest) is signed. The hash function converts any arbitrary input into a much shorter fixed-length value.
The private key object identifier (OID) from the OPTIGA™ Trust M key store is used to sign the digest, based on the chosen Signature Scheme. The message along with the generated signature is sent across to the intended receiver as shown in Figure 1.
For error correcting code (ECC), the length of the digest must be up to the key size used for signature, for example, ECC256 = 32 bytes, which requires 32 bytes of the generated digest to work. In the case of RSA, the length of the digest must be equal to the output length of the hash algorithm used, see Solution Reference Manual. The signature schemes supported by Shield2Go Security OPTIGA™ Trust M after the hash function are as follows:
Figure 1 Signature generation and verification process
At the receiver’s end, a signed hash along with the data is received. To validate the data’s integrity, the recipient first uses the signer's public key to decrypt the digital signature. The recipient then uses the same hashing algorithm that generated the original hash to generate a new one-way hash of the same data received. Finally, the hash values are compared to validate the sender.
The signature is verified using the VerifySign function in OPTIGA™ Trust M. Based on the signature scheme used, the signed digest and public key in the OPTIGA™ Trust M key store are provided as input to this function. Post decrypting the signature, the obtained hash and the calculated hash of the message are compared as shown in Figure 1. If the hashes match, the recipient can be assured that the public key used to decrypt the digital signature corresponds to the private key used to create the digital signature. There are two ways to provide the public key for verification:
The pre-provisioned public key certificates in OPTIGA™ Trust M are used for signature verification, see KBA235163. A newly generated key pair can also be used to generate and verify signatures. A key pair (public and private keys) is generated based on the chosen algorithm (ECC/RSA/AES) using the GenKeyPair function in OPTIGA™ Trust M. The OID for the generated private key to be stored is indicated and the public key can be exported or stored in one of the public key data objects or the trust anchor. The private key stored in OPTIGA™ Trust M is used for signing and the exported public key for verifying. This way, the sender is authenticated and the integrity of the message is verified from the time it was signed and the private key which identifies the sender is securely stored in OPTIGA™ Trust M.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.