Javacard - hash the client-side password sent to the applet

Question

If for example I have an applet which verifies the password (the password is created in the applet parameters) and the client software displays a dialog box to send the password (*****), as it happens so that the password is not sent in clear, what is the concept.

For me I think it is necessary to hash the password at the level of the client software, which sends to the applet and the applet decrypts the hashed password and compares it with the password passed in parameter during installing the applet.

or

the password at the level client is hashed and stocked to a server, applet hash the password passed on parameter that send to the client, and the client will recover the hashed password from applet to compare it with that of the server.

is this the right way to go?

Thanks for your help.

Answer 1

There is no "right way" with security / cryptography. There are usually multiple options with varying levels of security.

Usually the password or PIN is used to unlock the usage of a private key on the smart card. That private key is then used to create a signature, which can be used to login to a system. For this the server needs to trust the public key of the user. The latter is done using certificates / PKIX; the key pair is generated when the card is personalized, and the public key ends up in a certificate stored on the card. This certificate is signed by a trusted entity.

In this case the password is generally not hashed. It is simply send to the chip on the smart card. This chip is trusted with it as it can usually be visually identified. Furthermore, the connection to the chip is trusted because it is very local. Finally, as with most PIN's, the password security is protected because the chip cannot be hacked and because it allows only a certain level of retries.

If the connection to the smart card cannot be trusted you'd need a secure channel to it. For that the identity of the smart card may need to be established.

---

Just hashing a password before it is send to the smart card won't do much: the problem is that the hash becomes the new password where the smart card is concerned. So sniffing a static hash will allow an attacker to replay it to the smart card.