elibon99
commented
9 months ago The simple answer would probably be to change the password (from default to something else) before exposing the YubiHSM or protect the connector service with HTTPS and client authentication. The default password is used as a mechanism to allow the receiver of an YubiHSM to make the initial configuration (which should include removing default).
However, you can accomplish something close to what you are suggesting with asymmetric authentication (only available on YubiHSM with FW 2.3 or later) via attestation. Every YubiHSM has a unique device public key. After logging in to the YubiHSM using the "default" password you can ask for an attestation of this key. The result is a certificate signed by the default attestation key, which you can verify to know it is a genuine YubiHSM (a "fake" YubiHSM cannot generate such a signature). After this you could switch the default auth key (which is symmetric, based on the default password) with an asymmetric one. Upon successfully authenticating (asymmetrically) to the YubiHSM, utilizing the attested device public key, you can confidently ascertain that you are communicating with the correct YubiHSM. A MITM cannot be performed in this case since a MITM cannot authenticate with this key.
Let's assume this scenario:
However, a MITM attack can be performed as the attacker can pretend to be the YubiHSM and tamper with the commands if they have the initial password. How can this be prevented? Generally I would expect some end-to-end encryption and device cert attestation done but I don't see them here (please point out if I missed it). I would like to know if there's some way that we can send secured messages even if it uses the default password. This problem isn't present in some alternatives like SmartCard-HSM, which does not use the password to set up the secured connection.