Added a PW4 duress PIN for self-destruct functionality

[thotheolh]

Created a new type of PIN called the PW4. It's main functionality is for duress and coercion resistance function when at as a last resort the user reveals PW4 instead of PW1 or other PWs.

PW4 is entered like a normal PW1 with the difference being once PW4 is triggered, it will immediately wipe all the PGP keys as a user triggered tamper response.

A new function called checkPIN would take in a targetPIN (PW1) and a PW4 and do comparison. During checkPIN function, it will randomly select to check PW4 first or check target PIN first in an effort to prevent power glitching attacks on the chip.

A PW4 has the default trigger PIN code of 'KABOOM!!!' and the user calling CHANGE REFERENCE DATA with P2 = 0x84 would supply the first half of the data as PW1 and second half as the intended PW4 actual PIN code that the user desires. By sending PW1 concatenate with PW4 behind, the PW1 is to allow an actual user to authenticate into the card to proof that it is the actual user (PW1) who is going to issue a command to change PW4 PIN code.

The PW4 tamper trigger is actively listening under these conditions:

• PW1 activities (sign, decrypt, authenticate by PGP keyset)
• Changing of PW1 PIN code
• Changing of PW4 PIN code

PW3 and RC activities are left unaffected by PW4 tamper triggering activities to prevent accdientally tripping the PW4 by accident by PW3 or by RC activity.

Under duress situation when a user maybe coerced by captives, users are recommended to do the following OPSEC measures:

• Resist revealing any PIN code initially
• Upon further stress applied (during interrogation and whatsoever), reveal PW4 in a reluctant manner when held under captive).
• When asked to enter PIN code, only supply PW4 and never reveal PW1 as a last resort.

Email me at : twzgerald@gmail.com for further communication.

[coveralls]

Changes Unknown when pulling 8de6322387b863b604bdc05d4e02c82a44c5f90a on thotheolh:master into \ on Yubico:master**.

[a-dma]

Hey,

fist off, thanks for the contribution. I'll be completely honest. Right know for us is hard to merge this, it diverges too much from the official OpenPGP Card specifications. However, I think it's an interesting addition. I'll try to contact the people who write the specifications and see what they have to say about it.

This will probably take a while.

[thotheolh]

Hi. I have attempted to contact Achim Pietig who maintains the OpenPGP card standard but to no avail for a while. Do contact Achim Pietig (author of OpenPGP card standard) and seek advise. Also, it would be nice if Achim Pietig could include such a feature in OpenPGP card 4.0.

[a-dma]

Yes, I had a quick discussion with him. It's always very tricky to add this kind of things to specifications and as I said it takes time, so don't expect a super quick turnaround.

Let's see how it goes :)

[coveralls]

Changes Unknown when pulling fcadeb4002065620db2e9bd18118d576a36f26e9 on thotheolh:master into \ on Yubico:master**.

[thotheolh]

I wanted to open a new pull request and create another topic but somehow my changes were detected and included inside here so I have no choice but to put my comments here for my new changes.

I have uploaded an additional change to the PGPKey class by shifting the tmpBuf for setDPX() method to the main OpenPGPApplet using a shared tmpPGPBuf instead. This reduces the overall RAM memory consumption from somewhere around 1900+ bytes of original RAM usage to around a calculated 1694 bytes instead with a 256 bytes reduction. This makes OpenPGP applet better suited for low RAM smart cards.

You can selectively use my changes by copying (manually) the RAM memory optimization portion as needed.

[dschuermann]

@thotheolh Create a new branch in your fork and then cherry pick the specific commit from your master branch. Then you can open a new pull request here.