Electronic signature requirements [closed] - php

Question

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Hello Stackoverflow community,
I have a difficulty regarding electronic signature and especially how to apply the law of Singapore in terms of technical requirements.
By law, Singapore accepts electronic signatures if the signature is:
unique to the person using it;
capable of identifying such person;
created in a manner or using a means under the sole control of the
person using it; and
linked to the electronic record to which it relates in a manner such that if the record is changed, the electronic signature would be invalidated.
We are able to make the electronic signature via HTML5 canvas then save it as a data base64 string. That means point 1., 2. and 3. are ok.
Problem comes with point 4., we can indeed combine the signature and data in an encrypted string however, as we have both the signature and data we would be able to edit the data and create a new string:
|id|name|price|signature|final_hash|
------------------------------------
|12|test|40000|data:base|3edcde4642|
So we thought of another way, which is to mix some parameter we do not know into the final_hash such as the IP address of the signatory, his/her user agent... however, as we do not save these values, this means that we will not be able to check later on if some values were modified.
That's where we are stuck, do you have any idea on how to do this? To me, it seems impossible to satisfy both being able to check if no data was modified and being unable to modify the data later, but I may be wrong of course.
Thanks a lot for your help!

Answer 1

Note: I use the term "document" to refer to whatever it is you want to sign.
Some Misconceptions
First off, what you get from using HTML5 canvas or similar approaches is not a signature but a fingerprint. What I mean by that is that it identifies the client, but it cannot sign a document (at least not alone). Two caveats:
The fingerprint is of the browser, not of the user.
There will be collisions. In fact, for the sake of privacy, there is a push to make fingerprinting browsers harder, mainly because companies could use fingerprinting to track you without cookies.
You should not sign by concatenating the fingerprint to the data. That is not a signature, that is a salt, and not the best approach to salt either.
By the way, ClientJS is a good tool to create browser fingerprints
Your requirements
unique to the person using it;
capable of identifying such person;
Those requirements spell "Identification". It means you need an ID of the person.
created in a manner or using a means under the sole control of the
person using it; and
This requirement spell "Authentication". It means you need to verify that people are who they claim to be. You probably have seen the theory, you do this by: a) something the person is (i.e. biometric) b) something the person knows (i.e. a password) or c) something the person has (i.e. access to an email account, a cellphone, etc...).
It bothers me that you seem to be using browser fingerprint to do both identification and authentication. This could make it too easy to fake requests to appear to be another user.
Usually what you would do in this situation is to have a traditional authentication process with username and password, then issue a cookie. Why do you avoid that?
linked to the electronic record to which it relates in a manner such that if the record is changed, the electronic signature would be invalidated.
This requirement spell "Signature". This probably means that the electronic record will be public and we want to have protection against counterfeits.
it seems impossible to satisfy both being able to check if no data was modified and being unable to modify the data later
The general idea is to have the signature become invalid when the document is modified. If you want to make the modification official, you need to create a new signature.
In order to prevent third parties to create a signature from the modified message you need to add some secret key. Now, that raises two questions:
Should third parties be able to verify the signature? If they should, you need an asymettric algorithm.
Should the documents be protected against you (or people with rigthful access to the server)? If they should be protected, it suggests you need a secret for each user. The simplest solution is to have a password.
Asymmetric solution
To implement an asymmetric solution in PHP I suggest to use phpseclib.
Follow their example to create a key pair:
include('Crypt/RSA.php');
$rsa = new Crypt_RSA();
$pair = $rsa->createKey();
$privatekey = $pair['privatekey'];
$publickey = $pair['publickey'];
The code will use entropy collected from the server to generate the key pair.
Then you can use it to do simple RSA signature and verification.
include('Crypt/RSA.php');
$rsa = new Crypt_RSA();
$rsa->loadKey('...'); // private key
$plaintext = '...';
$signature = $rsa->sign($plaintext);
$rsa->loadKey('...'); // public key
echo $rsa->verify($plaintext, $signature) ? 'verified' : 'unverified';
If you need to verify signatures on the client, you can use jsrsasign.
For your use case, you only need one key pair for the server. The concept here is that the server is signing the document. If the signature matches, it means that the fingerprint is correct.
Either way, you should keep your private keys secret (do not ever send it to the client), and you can share the public key with whoever you need to be able to verify the signatures.
Using this, the server can sign the document that identifies the user / client (including the fingerprint, for example) and publish the document plus the signature. The document would be perfectly readable (it is not encrypted), but if somebody modifies it, the signature would no longer be valid.
To verify the signature they need the public key. However, the public key is not useful to create a fake signature, to do that they would need to get the private key.
Symmetric solution
The main advantage of a symmetric algorithm is in performance. The disadvantage of a symmetric algorithm is that you need the key to verify it.
Therefore, if you need third parties to be able to verify the signature (or even if you need the verification to happen on the client side) you would be exposing the key used to create the signatures.
In this case, the signature is easier to implement. To sign use hash_hmac with the key. To verify the signature, repeat the process and compare it with the signature you got.
A key for each user
I am not sure if you are trying to protect the data from yourself. That is, if your objective is to prevent you (or your team / or whoever manages the servers) from tampering the data.
If that is what you want, you can password protect your keys. For the asymmetric solution, phpseclib allows you to set a password used to cipher the private key (and therefore needed to be able to sign). For the symmetric solution, you can use the password directly as key.
If what you want is to generate that password from your fingerprint, you can do that with a key derivation function... yet, remember that there will be fingerprint collisions, and that having a unique browser fingerprint can be considered a privacy concern.
Key derivation functions
You can get a cryptographic key from external input (browser fingerprint, user password, etc...) using a key derivation function.
From worst to best option:
Truncate to size the fingerprint. DON'T DO THIS EVER. This wastes entropy from the fingerprint. It makes collisions very likely.
Hash the fingerprint. DON'T DO EITHER. Anybody who can take the fingerprint and knows what hash you use can get the key.
Hash the fingerprint concatenated with pepper (the same salt for everybody). Still not good
Hash the fingerprint concatenated with salt (unique for each individual). Many say this is the first sane option. Yet, you should keep in mind to use a good hashing algorithm.
Use a hash based message authentication code. hash_hmac. For me, this is the first sane option. It costs you virtually nothing to change a hash of a concatenation to a call to hash_hmac. In addition, it will protect you from partial preimage vulnerabilities of the hash algorithm (known or to be discovered).
Use a dedicated key derivation algorithm. Among the standard PHP function, I suggest hash_hkdf or hash_pbkdf2.
Note: sometimes people (including me from the past) refer to these key derivation functions as hash functions. The reason is that when you use them, you do not call your regular hash function (directly) and what they give you is technically a hash. Yet, in reality, they are not hashing algorithms; they are algorithms build on top of hashing… in fact, one of the parameters to use them is what hash function to use internally.