Peter Lebbing: >> By "part" I don't mean split one key in halves, but rather use two keys. > It's an interesting thought, I'll definitely give you that. However, if you > need > that kind of protection, I don't think you should use a normal computer with a > normal operating system. It seems to me, to attack your smartcard, they would > need to either hack your PC, or have physical access. In both scenarios, the > key > on your hard disk is not secure anymore either. > > Can you think of a scenario where the on-disk key adds security beyond the > smartcard?
Yes. Scenario #1 ########### Adversary capabilities: - Can physically steal the smartcard. - Capable of dismantling a smartcard to extract the key its holing. [Maybe not now, but maybe in a few years the tool required to so so will be available. Only making up the scenario here.] - Not capable of breaking gpg's key encryption/password protection. - Not capable of rubber-hose cryptanalysis. - Not capable of installing a miniature camera and/or hardware keylogger. Scenario: - Password of gpg key has sufficient strength (length, entropy, you name it). - Power of computer holding the key is off long enough. - No data left in RAM (hence no coldboot attack possible). - Adversary hasn't done an remote/online attack, therefore the password of the gpg key is still secret. - Adversary obtained smartcard and hdd by using a one-time physical attack. (For example a robber could steal a notebook and smartcard.) Result: - 1) smartcard only: fail [adversary extracts key from smartcard] - 2) smartcard + gpg/encrypted/password protected key: ok [adversary extracts key from smartcard, but fails to break gpg's encrypted private key] - 3) gpg/encrypted/password protected key only: ok [adversary extracts key from smartcard, but fails to break gpg's encrypted private key] I'd prefer result 2) and 3) over 1). ########### Scenario #2 ########### Adversary capabilities: - Not capable of stealing/dismantling a smartcard to extract the key its holing. - Not capable of rubber-hose cryptanalysis. - Not capable of breaking gpg's key encryption/password protection. Scenario: - Adversary compromises the victims operating system using a remote/online attack. - Adversary reads the password while it is in RAM. - Adversary downloads the victim's private gpg key from hdd. Result: - 4) smartcard only [there is no key the adversary could download from hdd]: as usual, key can be abused as long as smartcard PIN is cached, at least the smartcard key can not be extracted; no further abuse possible once detected, smartcard removed [and operating system reset to clean/immunized state] - 5) smartcard + gpg/encrypted/password protected key: as usual, key can be abused as long as smartcard PIN is cached, at least the smartcard key can not be extracted; no further abuse possible once detected, smartcard removed [and operating system reset to clean/immunized state] - 6) gpg/encrypted/password protected only: whole key can be extracted and abused as long as not revoked I'd prefer result 4) or 5) over 6). ########### Conclusion: We can't be sure of adversary capabilities. To archive the best possible outcome in both, in scenario #1 and #2, it seems to be, that it's worthwhile to combine the security properties from both, smartcards and on key encryption. _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
