How do RSA smartcards prevent key exfiltration?

Question

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?

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.