Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision Next revisionBoth sides next revision | ||
public:papers:primality_esorics20 [2020-07-02 11:12] – created xsvenda | public:papers:primality_esorics20 [2020-09-14 15:37] – xsvenda | ||
---|---|---|---|
Line 11: | Line 11: | ||
{{fa> | {{fa> | ||
+ | |||
+ | \_{{fa> | ||
+ | |||
</ | </ | ||
</ | </ | ||
Line 17: | Line 20: | ||
<TEXT align=" | <TEXT align=" | ||
- | <popover trigger=" | + | <button type=" |
- | <button type=" | + | |
- | </ | + | |
\_ | \_ | ||
- | <popover trigger=" | + | <button icon=" |
- | <button icon=" | + | |
- | </ | + | |
\_ | \_ | ||
<button collapse=" | <button collapse=" | ||
Line 43: | Line 42: | ||
<panel type=" | <panel type=" | ||
- | We analyse whether the smartcards of the JavaCard platform correctly validate primality of domain parameters. The work is inspired by Albrecht et al.[1], where the authors analysed many open-source libraries and constructed pseudoprimes fooling the primality testing functions. However, in the case of smart-cards, | + | We analyse whether the smartcards of the JavaCard platform correctly validate primality of domain parameters. The work is inspired by Albrecht et al.[[https:// |
</ | </ | ||
===== Further research ===== | ===== Further research ===== | ||
- | FIXME | + | Data, generation scripts and attack demonstrations: |
- | <button type=" | + | <button type=" |
+ | |||
+ | |||
+ | ===== 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/ |