Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
public:papers:primality_esorics20 [2020-08-04 11:36] – [Fooling primality tests on smartcards [ESORICS 2020]] xjancar | public:papers:primality_esorics20 [2021-12-04 20:28] (current) – [Summarizing video] x408178 | ||
---|---|---|---|
Line 11: | Line 11: | ||
{{fa> | {{fa> | ||
+ | |||
+ | \_{{fa> | ||
+ | |||
</ | </ | ||
</ | </ | ||
Line 19: | Line 22: | ||
<button type=" | <button type=" | ||
\_ | \_ | ||
- | <popover trigger=" | + | <button icon=" |
- | <button icon=" | + | |
- | </ | + | |
\_ | \_ | ||
<button collapse=" | <button collapse=" | ||
Line 46: | Line 47: | ||
===== Further research ===== | ===== Further research ===== | ||
- | <button type=" | + | Data, generation scripts and attack demonstrations: |
+ | <button type=" | ||
+ | |||
+ | ===== Summarizing video ===== | ||
+ | |||
+ | {{ youtube> | ||
+ | |||
+ | ===== Selected conclusions ===== | ||
+ | * We analysed nine different smartcards from five major manufacturers and found that all but one failed to properly verify the primality of the provided ECDSA and ECDH domain parameters. Furthermore, | ||
+ | * Due to the unavailability of primality testing functionality in the public JavaCardAPI and the blackbox nature of the smartcards, it is hard to systematically test domain parameters for primality. We propose a methodology to do so. | ||
+ | * We demonstrated Pohlig-Hellman style attacks in two scenarios for ECDSA/ECDH (one of which is new) and two scenarios for DSA/DH. The attacks lead to full private key recovery, assuming the attacker has control over the domain parameters. | ||
+ | * Issues found were responsibly disclosed to the affected vendors, but the vulnerability is not easily mitigated for the already deployed smartcards. The code responsible for the domain parameter validation is often stored in a read only memory without the possibility for an update. In addition, the missing primality testing function in the API prevents the developer the check the parameters on-card. | ||
+ | * Besides allowing API primality testing, full domain parameter validation and supporting only named curves (though this limits future flexibility) should mitigate the vulnerability. On a lower level, using either Miller-Rabin with random bases or the Baillie-PSW primality test should detect all composites. | ||
+ | |||
+ | ===== Acknowledgements ===== | ||
+ | J. Jancar was supported by the grant MUNI/ |