Remove hash-on-card extension?

arekinath commented 3 years ago

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 #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 commented 3 years ago

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 commented 2 years ago

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

Also see https://github.com/OpenSC/OpenSC/pull/2506#discussion_r810282268 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 commented 2 years ago

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

dengert commented 2 years ago

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 https://github.com/arekinath/PivApplet/issues/47#issuecomment-1055961536, 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 commented 1 year ago

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?

arekinath / PivApplet

Remove hash-on-card extension? #47