You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using PIN codes to authenticate are only secure under the assumption that the host computer does not have malwares that steal the PIN codes.
Yubikeys have touch buttons that are capable of triggering a touch event that can be used as a 2nd factor confirmation besides PIN codes. This prevents a stolen PIN code by a malware to authenticate without a physical human touch to trigger the authentication confirmation.
More secure element tokens are being produced daily that comes with the special touch button capability and this can be made used of to enhance PIN code security with an additional layer of human interaction.
The touch trigger takes the form of a specialized APDU command that only the USB controller of a USB token may send to the secure element chip.
The APDU is as below:
CLA = B0
INS = A0
P1 = 00
P2 = 01
LC = 00
The below describes the precise interaction between the Host, token's USB controller and Secure Element.
1.) Host computer sends Select AID APDU to USB controller. USB controller registers currently selected AID in it's RAM and forwards the Select AID APDU to Secure Element for applet selection. If the Secure Element sends an SW that is not a 0x9000, the USB controller will erase the AID from the USB controller's RAM.
2,) Whenever the touch button is activated, the USB controller will send the touch button APDU command directly to the Secure Element in a fire-and-forget fashion.
3.) To prevent the external environment (Host computer or other malicious actors) from triggering the touch APDU besides the actual human interaction with the touch button, all externally sent APDU command matching the combined CLA, INS, P1, P2 and LC of the special touch button APDU will be dropped by the USB controller of the token and not forwarded to the Secure Element and the token's USB controller will send a 0x6F00 status word.
4.) To allow cross compatible implementation of the above touch sensing feature on tokens or smart cards that do not follow this specification, this feature should allow safe commenting or removal of codes without impacting the rest of the feature set of OpenPGP card. If the applet with the touch sensor capability were to be compiled and installed onto a token or smart card without touch capability, the feature should be inert and not cause problem to the applet.
5.) A status flag concerning the touch capability must be implemented in the source code as a byte flag for applets desiring to incorporate touch sensing capability. The flag "HW_CAP_ALLOW_TOUCH" will be a permanently stored byte that will take a 0xFF for True and 0x00 for False. This flag will be checked and allow users to use the touch capability if it is set to True. This flag must be changed from the source code (and compiled as a CAP file) and not allow users to "soft-edit" after the fact once loaded into the hardware. This flag is to ensure maximum compatibility with available hardware in the event that whoever that wants to deploy the YKNEO OpenPGP applet does not want to comment or remove the entire chunk of touch sensing codes due to possible messiness and all they need to do is change the flag to 0x00 (False) to ensure it will not impact their hardware without needing to delete codes from the applet. This also gives hardware supplier who are interested to supply touch sensing capable hardware to back their PIN entry for 2nd factor confirmation to be able to immediately deploy the touch sensing capable code without needing to mess around and add their own codes which all they need to do is enable the "HW_CAP_ALLOW_TOUCH" flag to 0xFF(True). This allows smooth integration with the original OpenPGP standards since it does not need additional commands for management and can be considered a "safe" grey area of implementation without terribly messing the original OpenPGP standards.
The text was updated successfully, but these errors were encountered:
Using PIN codes to authenticate are only secure under the assumption that the host computer does not have malwares that steal the PIN codes.
Yubikeys have touch buttons that are capable of triggering a touch event that can be used as a 2nd factor confirmation besides PIN codes. This prevents a stolen PIN code by a malware to authenticate without a physical human touch to trigger the authentication confirmation.
More secure element tokens are being produced daily that comes with the special touch button capability and this can be made used of to enhance PIN code security with an additional layer of human interaction.
The touch trigger takes the form of a specialized APDU command that only the USB controller of a USB token may send to the secure element chip.
The APDU is as below:
CLA = B0
INS = A0
P1 = 00
P2 = 01
LC = 00
The below describes the precise interaction between the Host, token's USB controller and Secure Element.
1.) Host computer sends Select AID APDU to USB controller. USB controller registers currently selected AID in it's RAM and forwards the Select AID APDU to Secure Element for applet selection. If the Secure Element sends an SW that is not a 0x9000, the USB controller will erase the AID from the USB controller's RAM.
2,) Whenever the touch button is activated, the USB controller will send the touch button APDU command directly to the Secure Element in a fire-and-forget fashion.
3.) To prevent the external environment (Host computer or other malicious actors) from triggering the touch APDU besides the actual human interaction with the touch button, all externally sent APDU command matching the combined CLA, INS, P1, P2 and LC of the special touch button APDU will be dropped by the USB controller of the token and not forwarded to the Secure Element and the token's USB controller will send a 0x6F00 status word.
4.) To allow cross compatible implementation of the above touch sensing feature on tokens or smart cards that do not follow this specification, this feature should allow safe commenting or removal of codes without impacting the rest of the feature set of OpenPGP card. If the applet with the touch sensor capability were to be compiled and installed onto a token or smart card without touch capability, the feature should be inert and not cause problem to the applet.
5.) A status flag concerning the touch capability must be implemented in the source code as a byte flag for applets desiring to incorporate touch sensing capability. The flag "HW_CAP_ALLOW_TOUCH" will be a permanently stored byte that will take a 0xFF for True and 0x00 for False. This flag will be checked and allow users to use the touch capability if it is set to True. This flag must be changed from the source code (and compiled as a CAP file) and not allow users to "soft-edit" after the fact once loaded into the hardware. This flag is to ensure maximum compatibility with available hardware in the event that whoever that wants to deploy the YKNEO OpenPGP applet does not want to comment or remove the entire chunk of touch sensing codes due to possible messiness and all they need to do is change the flag to 0x00 (False) to ensure it will not impact their hardware without needing to delete codes from the applet. This also gives hardware supplier who are interested to supply touch sensing capable hardware to back their PIN entry for 2nd factor confirmation to be able to immediately deploy the touch sensing capable code without needing to mess around and add their own codes which all they need to do is enable the "HW_CAP_ALLOW_TOUCH" flag to 0xFF(True). This allows smooth integration with the original OpenPGP standards since it does not need additional commands for management and can be considered a "safe" grey area of implementation without terribly messing the original OpenPGP standards.
The text was updated successfully, but these errors were encountered: