Remove hash-on-card extension?

[arekinath]

Currently debating whether to remove the ECDSA hash-on-card extension from future releases of this applet.

• Most of the jc222 cards we tested it with (e.g. J3D081) are now known to have serious side-channel leaks in their ECDSA impls which enable easy and quick key extraction, so people probably shouldn't use them anyway
• Removing hash-on-card would let us probably reduce our need for most of the fancier features in the SGL code (we will no longer need to regularly deal with big payloads coming in to be signed, since it'll just be hashes) and simplify that logic a lot (I know several people have raised concerns about how complex the memory management there is)
• Removing it would also help contain our build options explosion a little, since we no longer have to deal with the two separate ECDSA modes
• And it might let us be a little more standards-compliant with our APT, since we wouldn't have to advertise the hash-on-card algos any more? (see discussion in Current PIV Answer to Select Parsing in PIV AID  #45) We might at least be able to get the size of the APT down a bit.
• It seems like no clients except pivy have ever implemented support for using it (though this isn't that surprising)

[kategray]

Since the side channel leaks defeat much of the purpose of the card, it's probably better to remove it and improve security-by-default.

[dengert]

If "Hash on card" is expecting software to do all but last round of hash, there is a problem.

Also see OpenSC/OpenSC#2506 (comment) and htttps://github.com/openssl/openssl/issues/17688

OpenSC had one card that would allow for last round of SHA256 or SHA1 to be done on card. This required software to do the all the rounds but the last and access to intermediate hash to send to the card. OpenSSL-3.0 is deprecating the ability to access intermediate hash data. So for now, OpenSC is not going to support hash on card when used with OpenSC, as there was no response from any developers or users of the card.

[arekinath]

@dengert That doesn't sound like a problem so much as a vote in favour of removing it, if you ask me :)

[dengert]

Yes remove it

…

On Tue, Mar 1, 2022, 5:21 PM Alex Wilson ***@***.***> wrote: @dengert <https://github.com/dengert> That doesn't sound like a problem so much as a vote in favour of removing it, if you ask me :) — Reply to this email directly, view it on GitHub <#47 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGTIMICQWNW5RUZPE3UMFDU52RA5ANCNFSM4YYNQCRA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[no-usernames-left]

Most of the jc222 cards we tested it with (e.g. J3D081) are now known to have serious side-channel leaks in their ECDSA impls which enable easy and quick key extraction

@arekinath Are you referring to LadderLeak? If not, do you have a link handy which details this?