The signer’s identity is represented inside the digital signature with the signer certificate. This digital certificate is created then the user signs up to .ID and updated after the real person verification.
Very few digital signature providers can actually do that. Instead, they are actually “signing” documents using the certificate issued to themselves and not to the users.
Once the signature is given, we add the identity certificate used for signing in to the same signature file where the file hash is stored.
In the signature example below you can find the certificate in encoded format in lines 23 to 25.
If you want to decode it and make it readable, you can use online certificate decoders. Like this one for example: https://certlogik.com/decoder/
This is how the identity certificate actually looks like when decoded.
You can see the data in your digital certificate in your app under the Digital Identity section.
Once we have secured files integrity and secured personal digital identity to the signature, we need to get the person consent securely to bundle all that together into the digital signature. For this, we take an advantage of a security technology protocol called Public Key Infrastructure (PKI), which allows the receiver to validate the origin (sender) of the message.
If you already know how PKI works, you can skip the next part and jump right into the final section where everything is bound together.
So how does PKI work?
In simple terms, when a user signs up, .ID app creates a connected key-pair: one key is called a private key and another one is called a public key. The first one is something only the user (app) knows, but the public key can be given to any receiver to validate that the message comes indeed from the original user.
When a user now sends a message to the server and signs it with a private key, the receiving party can now check using the public key whether the “signature” under the message is indeed from the expected sender.
The receiver needs to get three things from the sender:
After receiving those things, she combines the received public key and signature and gets a certain digital fingerprint out of it (“Validation digest A”). As of next, she runs the same hashing algorithm on the original message and gets the second digital fingerprint (“Validation digest B”).
If the values of both digests match, then the receiver can safely say that the original message indeed can only come from the person who owns the matching private key to the public key coming with the message.
To try PKI principles at home, follow this thought experiment.
Since private and public keys are connected, we can think about them as two numbers that come from the same determined “wholistic source”. So if the “wholistic source” is 10 and the private key is 7, then the public key must be 3.
Now, let’s say I want to send you a message which is just one number, let’s say it’s “8”. And I will tell you that my public key is “7”. And if I sign my message “8” with my private key my signature results in “11” (8+3).
For validation, you need to know that using our agreed protocol, the “wholistic source” is 10.
Since my message was “8” and my signature was “11”, you can now validate whether the signature can be tracked down to me:
If those numbers match, then the message and signature could not come from anyone else than me.
As you can see, you did not need to know my private key to validate the signature and that message came from me.
Please bear in mind that the PKI in real life is not that simple of course.
To ensure that only you can send us the signing command, we need to protect your private key carefully. For this reason, the private key inside your mobile phone is also carefully encrypted and can be unlocked only if you know the 6-digit PIN code.
So a potential hacker, who wants to sign on your behalf, first have to get your mobile phone, then get into that (hopefully you have enabled phone lock by PIN-code or biometrics), and then guess your 6-digit PIN-code with 3 attempts.
However, signature’s cryptographic verification is not the only part of signature validation. We also validate the associated certificates and full “chain of trust” (a fancy term to the certificates that issue/sign other certificates).