On 21 September 2015 at 10:16, Ish Sookun <ish.sookun_at_lsldigital.mu> wrote:
>
> On 2015-09-20 22:44, S Moonesamy wrote:
>>
>>
>> Your explanations says that the reader contains a "decryption key".
>> It does not make sense to have a "decryption key" stored on each
>> reader. You would be creating a security problem instead of solving
>> one if you do that. :-)
>>
>
> The card readers should come equipped with a Security Access Module [1]
> which is a sim-like chip that contains the decryption key. Without this key
> the address and fingerprint minutiae can't be read.
I would agree with S. Moonesamy on this. It is certainly not
impossible, but it would be very unwise to do this. Here are my
thoughts with the caveat that it has been a few years since I explored
smart card crypto and I am not a cryptographer.
Theoretically, either there is a single decryption key or there are
many decryption keys (up to a maximum of one per user/card). Assuming
that the secure memory bounds of the reader are sufficient to store
all keys and the reader does indeed store all keys, then one
compromised device is sufficient to compromise all cards.
Alternatively, it is possible that the reader fetches the appropriate
key on-demand. In this scenario, the strength of the secure
connection from server to reader must be at least as strong as that of
all other components of the system.
Encryption provides confidentiality. If the cryptographic system used
has sufficient strength, then a malicious entity cannot determine
plaintext from its ciphertext. However, once we need to perform
computation upon encrypted data, confidentiality cannot be guaranteed,
as decryption must take place. In the case of fingerprint matching,
the matcher function will require the encrypted fingerprint template
and/or minutiae to be decrypted before it is passed to the matching
algorithm. At this point, any vulnerabilities in the SAM can be
exploited to observe the inputs to the matcher. Fully Homomorphic
encryption schemes [1] provide a solution to this problem by allowing
computation on encrypted inputs, but this is still largely in the
research stage.
The fingerprint matching application could (and in my opinion, should)
be implemented on the smart card. The reader reads the fingerprint,
submits the relevant properties to the secure element of the card
within which the fingerprint matching takes place. In this scenario,
the reader does not need to know the key used to encrypt the
fingerprint minutiae, as it simply supplies the input (fingerprint)
and receives the result of the matching function (match is true or
false).
Of course, given the "security through obscurity" of the national
identity card scheme, it is difficult to know what is actually
happening.
Regards,
Dr. Stephen Naicken.
References:
[1]
https://crypto.stanford.edu/craig/craig-thesis.pdf
Received on Mon Sep 21 2015 - 19:14:42 PST