Extracting private keys directly from the card is nearly impossible. With some acid package destruction and electron microscope work, a skilled team, and enough time, money, and luck you can in theory extract keys but it involves not only physical access but a scenario where the card will be physically destroyed.
Gerald Davis, Information Security Stack Exchange

While this is obviously true in the anthropic-principle sense ("everyone knows that a key exfiltration attack against the G+G FIPS 201 SCE 7.0 would make the news"; I wouldn't be asking this question if exfiltration weren't being somehow prevented on modern smartcards), I'm wondering: how do non-exfiltrable RSA smartcards protect themselves against key exfiltration?

At the API level (not the contractual, legal, social, or psychological level), what stops a rogue cardbearer from writing a piece of software on their own PC that sends some CPA value m=8388609 to the card for signing (or CCA c=2147483649 for decryption), entering their true signing/decryption PIN, then doing cryptanalysis on the signed or "decrypted" values to factorize n outright?

To be clear, I am not asking about how chosen-plaintext and padding oracle attacks are done (which would be more appropriate for Cryptography Stack Exchange).

I am, instead, (as stated in the title) asking how modern RSA smartcards prevent authorized users from launching such attacks. What security control, physical mechanism, interface limitation, etc. is used on modern RSA smartcards to enforce, say, proper padding?

  • Is the question, why don't cryptographers do cryptanalysis on plain text to find the key? On most algorithms they are, but algorithms in the wild are not presently vulnerable to this attack to a degree which makes the attack feasible.
    – foreverska
    Commented Sep 12, 2022 at 21:27
  • The point is to let attackers cryptanalyze to their heart content and still be safe. It is 100% assumed people will do their damned best to extract they keys, some using extensive hardware and know how. The cards are engineered with that in mind. Commented Sep 13, 2022 at 8:31
  • @BrunoRohée "The cards are engineered with [rogue users] mind." -- I know that; that's the context of my question, but I'm wondering what physically stops a rogue user (who is able to sign and decrypt messages) from attempting C*A attacks. If I were to learn some kind of smartcard interfacing SDK and attempt to build a malicious application to exfiltrate the key from my "own" smartcard, what obstacle would stop me? Do the cards reject improperly-padded messages? Do they pad them on-die? Is the solution something else? Commented Sep 13, 2022 at 17:53
  • You'd need to go in the details of the card you want to attack, but they do enforce protocol compliance (e.g. ISO/IEC 7816) to the best of their abilities (part of the certification of such cards) but are also generally aware and have counter measures against timing attacks, power usage analysis, fault injection... Commented Sep 15, 2022 at 15:43

1 Answer 1


No common modern ciphers or MAC constructions - certainly none of the ones that a smartcard or other HSM will even support - are known to be vulnerable to any cryptanalysis where chosen-plaintext or chosen-ciphertext attacks will reveal the key. More specifically, such an attack is computationally infeasible; even with attacker-chosen plaintext and/or ciphertext, it should not be possible to find the correct key by any means faster than brute-force guess-and-check, and the entropy of the key is sufficient to make that totally infeasible with modern computers, or those predicted for the mid-term future (the far future... who knows. Eventually, if Moore's Law keeps on course, a pocket calculator might crack RSA-4096 in a moment. But that's literally hundreds of years away).

If such a vulnerability were to be discovered, it would be up to the smartcard vendor to modify their card firmware to reject the unsafe values (but older cards would probably be vulnerable). It would also almost certainly result in the immediate deprecation of (that version of) the primitive or construction, because it's far too easy to launch such attacks. In addition to hardware security modules, you also have software ones (e.g. Windows' CryptoAPI, or JS SubtleCrypto non-extractable CryptoKey objects), social engineering attacks (suppose you know Dave, who always sends his emails plain-text signed with GPG, and ask him to send you a "nonsense" string in an email), and many other vectors. It would be a disaster.

Security against such attacks is like resistance to preimage attacks in a secure hash function; it's not literally the first requirement of a primitive or construction, but it's absolutely going to be considered before any serious cryptographer even bothers describing a new cipher to somebody else, much less writes it down to submit it for review. The reviewers will certainly also consider such attacks, quite extensively, and reject any proposal vulnerable to them. Immunity to such attacks might be described as part of the "table stakes" in modern cryptography.

(It is worth noting that this is the kind of thing that amateurs often fail to account for. That is part of why "never roll your own" is such important advice in cryptography; many people aren't familiar with the common attacks at all, or if they are, aren't familiar with how to construct ciphers that are immune to them. The reviewers who consider ciphers for widespread adoption certainly are, though... which is a good thing, because of course the attackers are too.)

While questions about applied cryptography are often asked and answered here, questions about theoretical cryptography (e.g. how resistance to chosen-plaintext attacks is achieved) or in-depth cryptanalysis are perhaps better suited to the sister site https://crypto.stackexchange.com.

  • None of what you've posted in the first edition of the answer is unknown to me as of asking the question. How do smartcards enforce proper implementation, especially against a rogue user (such as a naive coworker signing nonsense)? Is message padding done on the card? If I sign a 10-terabyte archive, surely the average RSA smartcard doesn't have any way (such as hashing on-die) to enforce that I'm really passing it a correctly-hashed message, no? Commented Sep 13, 2022 at 17:46
  • e.g. Do smartcards reject messages with unset high bits? Are some padding or hashing schemes amenable to being done on-die? etc. Commented Sep 13, 2022 at 17:48
  • 1
    @JamesTheAwesomeDude Yes, padding is done on the card. You typically pass a hash to the card. The card doesn't know what it's signing, but it knows that it's signing correctly, and that's enough to not leak information that would allow the key to be reconstructed outside. Commented Sep 13, 2022 at 18:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .