[Project Proposal/Announcement]: Using chipcards as replacement for key files

2014-04-05
2014-04-08
  • Martin Hofmann
    Martin Hofmann
    2014-04-05

    I'm about to embark on a project to develop a KeePass plugin which should allow the use of chipcards as a replacement for key files.

    Goals

    I want to be able to open my KeePass database on various computers either with a chipcard, or alternatively with a key file (on a USB stick) on a computer where no card reader is available (or when the card is lost ;-).

    For now I want to use just the cards I already have (eg, my bank card, health insurance card, credit card), or else a generic and cheap memory card like the SLE 4432. That means, the chipcard is solely used as a readable data storage without security or encryption features - exactly like a key file on a USB stick.

    Using "real" smart cards (with processor, cryptographic functions, ...) is postponed to a later stage in the project.

    Technical concept so far

    • The plugin registers one ore more cards for a given user (account) on a machine with a card reader (eg in the HKCU registry subtree).

    • Each card can be associated with a PIN (a string of digits); this PIN is of course stored nowhere.

    • In the password dialog, the user can select the appropriate card, insert it in the card reader, optionally enter the PIN (if the card reader has a numpad), optionally enter the password for the database, and open it. While the card is available in the reader, the database can be locked and unlocked again without entering the PIN again.

    • The PIN is used to transform (encrypt) the card's content, in order to balance against the unprotected nature of memory cards.

    • The plugin derives a second key (additonal to the main password) from the card's content and the PIN.

    • This plugin-provided second key, together with the user-entered optional password, is used to open the database.

    • To open the database without a card reader, a key file can be used; this key file contains the equivalent of the (transformed) card's content and is created on request when registering the card with the plugin. As always, this key file shoud be well-guarded and probably encrypted (outside and independent of the plugin's actions).

    Comments, suggestions, and help appreciated

    While I see no problems with the programming and basic cryptography aspects of the project (I'm a mathematician, with a day job programming in C and C++), I'm new to writing plugins for KeePass. I did build and use the "Test Plugin" so far, I can more or less find my way around the KeePass source code, and browse through the plugin development documentation at

    http://keepass.info/help/v1_dev/plg_index.html

    (Btw: I'm using KeePass 1.* and thus the plugin will be for these KeePass versions.)

    Therefore, I can give no reasonable guess when this plugin will be ready to be published (on SourceForge).

    If any experienced KeePass plugin programmers are around in this forum, I would very much appreciate their support on plugin-API questions during the course of this project ...

    Don't hesitate with comments or suggestions on this project proposal, and if you are a security expert (as I'm not), please comment on the security implications of this concept!

    Kind regards,

    Martin Hofmann

    Added 2014-04-06:

    SourceForge project page KeeChipCard

    The new project page for KeeChipCard, as I have named the project, is up and running on SourceForge for several hours now. There is not much code yet, but a wiki, some documentation about chip cards and the planned cryptographic operations of the plugin -- and a blog and discussion forum.

    You're cordially invited to take a look, and to comment and discuss!

    tin-pot (Martin)

     
    Last edit: Martin Hofmann 2014-04-06
  • Paul
    Paul
    2014-04-06

    If you register the card in HKCU does this prevent the database being used on another computer? Can you store the registration in KeePass.config.xml for portability, or not store it at all?

    I think the PIN should be required and could be entered on the keyboard. As you are using non-secure cards the card is essentially a USB stick with the key file.

    Having the ability to unlock the database without the PIN if the card is still inserted defeats the principle of locking after a timeout. There are many reasons why you would leave your computer and not take your card with you.

    Rather than use a key file for recovery I suggest the user be required to enter the secret. This encourages the user to store the secret off the computer, where a key file would likely be stored on the computer.

    cheers, Paul

     
  • Martin Hofmann
    Martin Hofmann
    2014-04-06

    If you register the card in HKCU [...]

    It would (as intended!) only prevent the card from being used to open the KeePass database on another computer. On such a computer - where the card isn't registered in the users's account - one could still use the key file (preferably on a USB stick). That's also the case if this other computer has no card reader at all, or the user does not even have his own account there (say, an "internet cafe").

    I think the PIN should be required [...]

    Yes, the (non-secure) memory card is used in the same way as, and interchangeably with, a key file. And the PIN is intended to prevent an adversary who can gain access to the card from fully using it, that's correct.

    Having the ability to unlock [...]

    You have a point here. I thought that such a feature would be useful - and removing/inserting the card in the reader (like the FSC keyboard reader I use) is significantly easier than a USB stick. I'll think about it again.

    Rather than use a key file for recovery I suggest the user be required to enter the secret.

    I wanted to implement an alternative mechanism to opening the database with the card - for the obvious reasons, eg not all my computers have a card reader.

    The use of a key file suggested itself because the key file content is treated in a similar way to the use of a plugin-provided key. I doubt that it would be possible to implement a "password only" alternative unlocking mechanism, if that's what you mean. At least it would be much harder, I think.

    (I have summarized the interdependent cryptographic operations performed by KeePass and the planned plugin in a short text, which I will post in the project's wiki in a minute. This should make discussions like this easier.)

    So right now I think using a key file is the best (most affordable) solution. Since this key file is (planned to be) created when registering the card, one could always force it to be encrypted - with a pass phrase of any strength desired.

    The key file would then always be stored in this strong-encrypted form, and would have to be decrypted before using it for unlocking. Probably the best way for this would be to let the plugin do it: add a key provider entry "Use key file of card", or a button in a "Insert card" popup window, or something like this.

    Thanks for your insightful questions, Paul! Discussions like that really help me to clarify things (inside my own head, too ... ;-)

    Martin

     
  • Martin Hofmann
    Martin Hofmann
    2014-04-06

    I have added said cryptographic summary page now.

     
    Last edit: Martin Hofmann 2014-04-06
  • Paul
    Paul
    2014-04-06

    Maybe encrypt the key file with the same PIN? Then the card and key file are interchangeable.

    cheers, Paul

     
  • Martin Hofmann
    Martin Hofmann
    2014-04-06

    Yes, right - the PIN would also come into play when using the key file to unlock the database. As the sole encryption key however, I reckon it to be too weak. Thus I would like to encrypt the key file (maybe in addition to the PIN key) with a user-specified pass phrase (or password) at the time when the file is created (when registering the card for the first time).

    Thus the key file would always hang around in file systems in (strong) encrypted form.

    This file password would not be needed when using the card to unlock the database.

    To use the key file however, the plugin would first query the user for this password (I don't know if querying and using the PIN too would make any more sense in this case). The plugin would then decipher the file using this password, and would afterwards treat its deciphered content as if it came from the card and provide the appropriate 256-bit key to KeePass.

    Which would of course mean that the "key file" is no longer really a native KeePass key file, but you would have to use the plugin in order to make any use of it. (I don't think this is a harsh restriction, since you probably would run KeePass on a "foreign" computer from an USB stick, where the plugin can also reside. On the other hand, having a normal KeePass key file and a password, without the need for the plugin, would be a nice-to-have thing!)

    Note that this approach would be slightly different from what I had written on my "CryptoOps" wiki page (nice name btw, isn't it ;-):

    F = EY(N)( EK(d) )

    In this formulation, the card's content d is first encrypted with the user-specified key K and then furthermore encrypted with a key Y(N) derived from the PIN N - the result is the key file content F.

    Thanks again for your interesting questions!

    Martin

     
  • Martin Hofmann
    Martin Hofmann
    2014-04-06

    @Paul: Motivated by your questions, I have thought about the cryptographic aspects of the project once more.

    And I think I have a quite nice solution now, which has all the right properties:

    1. When registering a new card, the user specifies a PIN (optional) for the card. And if a key file is to be created, the user also chooses a password for the key file.

    2. Using the card, only the PIN is needed to unlock the database.

    3. Using the key file, only the password (and not the PIN!) is needed to unlock the database. In this case, no plugin is involved, any KeePass 1.xx instance should do.

    Concerning security, I think the following propositions hold:

    1. The card alone is useless to unlock the database without the PIN (which is never stored anywhere).

    2. The key file alone is useless to unlock the database without the password.

    3. From the key file, no information about the content of the card, or even it's type, can be gained.

    4. Even with access to the user's account where the card is registered, no information about neither the password nor the PIN can be gained.

    I have updated the cryptographic description in the project wiki accordingly, if you want to have a look at the details. - Which you certainly should! :-)

    Martin

     
  • Paul
    Paul
    2014-04-07

    1. I think a PIN should be mandatory from a security perspective. People are used to a PIN so that should be no problem.

    2. Is this using the "password + key file" in the KeePass master password box? Your equations in Case 3 & 5 differ.

    Card registration: As KeePass already has a user config file I think it makes sense to use that file for card registration.

    cheers, Paul

     
  • Martin Hofmann
    Martin Hofmann
    2014-04-07

    Hi Paul,

    1. I concur with you that it would probably make sense to require the user to define and utilize a PIN. The allowed rsp supported minimum and maximum number of digits in it can be determined later.

    2. Yes, the key file (generated for the card and associated with it) would be used exactly as any other KeePass key file: Use the KeePass password dialog to enter a user-defined password and to select the key file from the file system.

    I frankly do not understand what you mean by your remark about the difference between the equations in case 3 and case 5. In case 3, the (first) equation is:

    M = X(H(H(P) || F)) -- if the length of F is exactly 32;

    and the equation for case 5 is:

    M = X(H(H(P) || C))

    These equations are identical except that in case 3 the key file content F is used, where in case 5 the plugin-provided key C is used. The mathematician in me would say: a free variable (F) has been substituted by another (C), or simply: has been renamed. And this is the similarity that I want to exploit in order to allow both alternatives for the same database:

    a. Unlock the database with card + PIN;
    b. Unlock the database with key file + password.

    Martin

     
  • Martin Hofmann
    Martin Hofmann
    2014-04-07

    Ups, forgotten - Regarding the storage for card registrations:

    Basically I don't care whether this is stored in the Windows registry, or in the KeyPass *.ini file (in the user's account). As you point out, the ini (or config) file already exists, and so it seems naturally to use this file for storage: All the registered cards data would then be stored there, and not in the registry. - I'll try and implement this.

    That's probably the better option anyway, because all KeePass and Plugin data (except the databases and key files, of course) are then collected in just one place and file ...

    Martin

     
    Last edit: Martin Hofmann 2014-04-07
  • Paul
    Paul
    2014-04-07

    I was reading M = X(H(H(P) || H(F))), assuming your key file was not necessarily 32 bytes. I see you have stated it is 32 bytes - further down.

    cheers, Paul

     
  • Martin Hofmann
    Martin Hofmann
    2014-04-07

    Ah, I see. Indeed I chose to use a 32 byte key file (for now ...) for reasons of simplicity. To use a longer key file, one would have to balance the H(F) in the equation you cited with an additional application of SHA-256 inside the plugin (immediately before providing the key to the KeePass application) and would also introduce further complications: but it should be possible.

    I'm convinced that fixing the length of the generated key file to 32 bytes is equally secure; but remember that my "remarks on security" on the wiki page are rather preliminary, and I'll have another look at these questions.

    But only if I have verified that the concept is viable in the first place :-)

    Btw: Note that the key file content F is not equal to the key C which the plugin provides, even if the "generic" KeePass equations I repeated in my first answer would suggest that. What is instead equal to the provided key C is the key derived from the key file content F and the password W:

    H(H(W) || F) = C

    That follows from the equations in the section "The Key File for a Card" on my wiki page - oh, wait! Dingdingding! - There's a typo there: the outer H is missing! (I'll correct that in a moment.)

    As always, thanks for your helpful questions!

    Martin

     
  • Martin Hofmann
    Martin Hofmann
    2014-04-07

    Just this minute, I have corrected the type in the CryptoOps, and added some more words of explanation.

    Martin

     
  • Paul
    Paul
    2014-04-07

    In any case, it would be wise to concatenate the PIN with some random "salt" before using Y to derive the key from it. The salt would have to be stored on each computer where the card is to be used.

    How would you achieve this given a new computer?

    cheers, Paul

     
  • Martin Hofmann
    Martin Hofmann
    2014-04-07

    Well, up to now I envisage all (personal) computers I might ever use to be partitioned into three classes:

    1. Computers with a card reader, and where I have an account.
    2. Computers without a card reader, and where I have an account.
    3. Computers with or without a card reader, but where I do not have an account.

    Currently, all computers in class 1 are my own, but eg my own and venerable PowerBook G4 does not have a card reader and is thus in class 2.

    Furthermore, the computer at my workplace (I work as a programmer) has certainly an account for me, and I even have administrative rights, but it has no card reader: that's class 2.

    All other computers - say, in internet cafes, or computers at a friend's home, or the one of my brother - which I might use sporadically, are in the third class: I have no account on these, I won't install any software there (and I have never seen a card reader on any of these machines ;-).

    Now assume that I already have registerd my chip card on my everyday computer where I have an account (it's my own machine), I have a card reader and all that. That's the "old" computer.

    If the "new" computer you posit is going to be my own, it will certainly be in class 1 or 2. Which would mean:

    • If it has a card reader I'd like to use, I have to register the card with KeePass/KeeChipCard on this new computer, and would have to specify my PIN and my key file password (again). There would be no need to create the key file (again), but why not do it if the key material has to be entered anyway.

    • If it does not have a card reader I can use, like my workplace computer I use right now, I would probably store my key file in my account, and use it with my password to unlock the KeePass database - not much difference to what I have right now, where I use solely a password for my password database.

    On the other hand, if the "new" computer isn't going to be mine in any way or sense, ie I have no account on it and will not get one, therefore I can't install KeePass in the first place, and the machine will probably have no card reader anyway - well: then the best and I think the only reasonable way to use KeePass (logged into a guest account) there would be from a USB stick, containing a "portable" KeePass and the key file (remember that there's no need for the KeeChipCard plugin when using a key file), - and with some luck also the key file in mind :-) Again, this isn't much different what I do as a guest on the computer of, say, my mother: Plug in the USB stick, start KeePass, enter password - done.

    All in all this supposes that I do have an account on all of the computers where I'm going to use the chip card with KeePass - that's correct, if this was what you wanted to know.

    Where I don't use a card reader (because there is none, or I have no account), I just use a local key file (in my account) or an USB stick (in a guest account).

    Did this make any sense to you?

    Martin

     
  • Martin Hofmann
    Martin Hofmann
    2014-04-07

    Oh, now I suddenly see what you probably meant! ...:

    How does the salt value which was randomly created on the first computer get onto the next one - that's the "new computer" you think of, right?

    Ermm -- I simply haven't thought about this yet! The obvious way would be to copy the KeePass.ini file to the new computer - this would also obviate the need to register any cards on this computer, as all card data is in the *.ini file (by your proposal). So this would be a simple step.

    Otherwise, you're absolutely right, the "salt" value must be transferred to the "new" computer somehow else, maybe with support from the plugin.

    Or else: what if instead of a "random" salt value a pseudo-random salt value is used, which is derived (using hashes and ciphers) in a repeatable way from the card content (by the plugin during registration of the card), but is infeasible for an adversary to predict without knowing "enough" or even all: about the card content, the user's choice for key file password, the user's PIN.

    Martin

     
  • Paul
    Paul
    2014-04-08

    Thinking about my questions too much will have you off on several tangents.... ;-))

    Yes, how do you get the salt onto the new computer, given the old computer just died and you have a new one that you want to use. Just thinking about disaster recovery.
    If you have the key file you can regenerate the PIN / salt per you earlier response.
    If you have been wise and backed up the ini file you can restore that and away you go. Maybe the plug-in could help with the backup?

    cheers, Paul

     
  • Martin Hofmann
    Martin Hofmann
    2014-04-08

    I actually tend to like best the variant where the "salt" is derived from the users's key material, including the card's content. (Though that wouldn't be really a cryptographic "salt" any more, of course!) The primary reason for my speculation about "salt" was that the PIN alone is somewhat weak, and therefore additional entropy would be a good thing. I believe a derived and pseudo-random value would do.

    To back up the .ini file would not be required any more in this case - and password with key file rsp chip card with PIN would suffice to use the KeePass database on the new computer. Which is what I would like to accomplish in the first place.