4 ms·

First, I agree that there certainly are ways to do that more secure, like generate keys on-chip so that nobody knows them, but as I mentioned, together with sec

First, I agree that there certainly are ways to do that more secure, like generate keys on-chip so that nobody knows them, but as I mentioned, together with security we have to think about a good recovery plan, otherwise one has to come up with some back-way which compromises this (good) security. And I still believe that having a second U2F token easily accessible at my home is way less secure than even the current implementation of u2f-zero with the backups as explained. It's all about tradeoffs. Second, it looks like you're assuming that it's easy to just pick the MCU and read the code programmed into it. From my past embedded experience I know that e.g. MCUs by Microchip have read-protection bits in their config, so that if it's programmed with those bits set, one can't just read out the hex. Not saying it's totally impossible, but it takes considerable amount of time. This is the part of datasheet for e.g. PIC32: > 27.2 Device Code Protection > The PIC32MX Family features a single device code protection bit, CP that when programmed = 0, protects boot Flash and program Flash from being read or modified by an external programming device. When code protection is enabled, only the Device ID registers is available to be read by an external programmer. Boot Flash and program Flash memory are not protected from self-programming during program execution when code protection is enabled. HOWEVER, that said, after briefly looking at the u2f-zero's MCU datasheet (https://www.silabs.com/documents/public/data-sheets/efm8ub1-datasheet.pdf https://www.silabs.com/documents/public/data-sheets/efm8ub1-...), I failed to find any mention of read-protection, which does seem strange to me. Need to figure out more before I can say for sure. But nevertheless: suppose I get some time and reimplement something like u2f-zero but on the MCU which does have code protection, e.g. PIC32. Does it address your concerns?

jiveturkey 8y ago
> way less secure First you argue that the device is secure. When I point out that it is not, you switch tack to argue that when you take other factors into account, it's still "better" than doing it some other way because of some other factor, so overall security is good. You also want to conveniently forget aspects of your original argument at your blog, such as the defect with OTP that a phone can be stolen. A phone is much, much, much more secure than u2fzero. You're also insisting that your particular use case for needing a backup is the only and best use case. If you want to design a system for your individual desire and needs, that's great, but this doesn't generalize. I'm guessing most people will not want their device baseline to be insecure so that they can have a 2nd insecure backup at hand. As I hinted, the best solution is likely a cloud based token. This can be simulated with u2fzero by using a method similar to what @ecesena proposed. With either knowledge of an authorized external transport key, or by sharing a transport key, the atecc508a can share key material securely. I won't work out the details here, but basically you just need a single initialization-time secret that you store in the cloud. With that, you can take an arbitrary fresh unprogrammed u2fzero and initialize it to look like the one you lost. It has to be done this way (at user's direct control) because if you buy u2fzero's pre-programmed all security is lost. The secret blob can be stored on your [secure] phone and backed up in a safe on a piece of paper, or any other storage scheme which a particular user may require to meet their needs. Personally, I would store it in icloud. or if you used publickey, closer to @ecesena's proposal, you don't need to keep a secret. (at the expense of having to prepare the backup devices ahead of time.)
- dimonomid 8y ago
  I apologize for being inconsistent in my arguing; indeed, I "switch tack". That's because it's actually hard for me to constantly keep the full picture in my head, and sometimes I start thinking like "omg what I've done it's so insecure", but then realize that I already thought about it and still decided to use that strategy because of this, this and this. In fact I really appreciate you explaining all these details, and to be honest I need to find a decent amount of time to fully wrap my head around it; hopefully on the weekend I'll be able to. I doubt it will change my reasoning about my personal use case, but learning something new about security is never bad. Thanks for that! Hopefully I'll get back to you after learning more. Also wanted to make 100% sure: are you arguing just about the u2f-zero being insecurely implemented, or the whole concept of backup with the cloned and securely-stored token also being bad? If we imagine that e.g. yubico starts producing matched pairs of tokens (I doubt it would, but still let's imagine), primary and backup with the boosted counter, which are implemented securely enough etc - would it be still bad in your opinion?
  - jiveturkey 8y ago
    Diagrams help me. They do wonders to organize the thought process down to the most core ideas and cement it in your mind. I have planned to try "mind mapper" software to help with it but haven't done so yet. If you produce some kind of diagram I would be happy to review it with you. > are you arguing just about the u2f-zero being insecurely implemented, yes. the concept of a pre-cloned token is a good one. my main point of contention with you is that in your threat model, a lost phone is a security problem, yet a lost u2f is not. you need to revise your threat model or revise your solution.
    - dimonomid 8y ago
      > my main point of contention with you is that in your threat model, a lost phone is a security problem, yet a lost u2f is not I realized that I could explain my concerns better in the article. My biggest issue with the phone is not that it could get hacked, but that I could just lose it together with my u2f token (because, you know, I always carry both phone and u2f token), and thus get myself locked out of my accounts. So it's not about somebody attacking me specifically to get my 2fa data, but just about some bad luck happening which results in losing both u2f token and a phone which was a backup for u2f token. Instead of Google Authenticator we could use Authy, which synchronizes its database with the server, but Authy account could be recovered with SMS, which is anything but secure. I actually updated the article just now with that point. I really want having a backup which is rock-solid secure and reliable, you know, more reliable than any other 2nd factor I have. So having a token bricked into the wall or something like that would work. > you need to revise your threat model or revise your solution When I have a chance to reimplement the same backup concept having something more secure than u2f-zero, then yeah I surely will revise the solution.
jiveturkey 8y ago
> MCU which does have code protection http://www.break-ic.com/ http://www.break-ic.com/ in short, MCUs are not secure devices. the additional protection is great for surface level protection, and certainly sufficient for most threat models. but in this case, we are talking about an authentication token that is obligated to keep secrets. one cannot claim "secure implementation" without secure key storage. even the atecc508a doesn't really meet the definition of secure. eg, there is no eal certification. no reputable vendor would use it in a commercial security device. it's great for its target market though. unfortunately, there is no way for a hobbyist to acquire actually secure chips. something like the atecc508a will have to do.
- jiveturkey 8y ago
  although, for this implementation, you don't need to read out the chip anyway. you can just sniff the i2c bus to learn the keys.
  - dimonomid 8y ago
    > you can just sniff the i2c bus to learn the keys RMASK and WMASK, which smelled not useful to you, are there exactly to prevent this from happening.
    - jiveturkey 8y ago
      lol no. this is almost not even worth a response. the key managed here https://github.com/conorpp/u2f-zero/blob/master/firmware/src/u2f_atecc.c#L278 https://github.com/conorpp/u2f-zero/blob/master/firmware/src... and here https://github.com/conorpp/u2f-zero/blob/master/firmware/src/u2f_atecc.c#L208 https://github.com/conorpp/u2f-zero/blob/master/firmware/src... just means that the "actual key" (unmasked) only lives in MCU memory for a short time -- the time from when the mask is applied and then until return to caller and memory is cleared, in the enrollment case I linked. In the authenticate case, it lives quite a bit longer because the stack space used for key storage isn't zero'd. The atecc508 doesn't use or know how to use the mask. The actual key used for the encryption is passed in the clear over i2c. (note that the key derivation you suggest is wrong because of the extra xor masking.)

jiveturkey 8y ago

> way less secure First you argue that the device is secure. When I point out that it is not, you switch tack to argue that when you take other factors into account, it's still "better" than doing it some other way because of some other factor, so overall security is good. You also want to conveniently forget aspects of your original argument at your blog, such as the defect with OTP that a phone can be stolen. A phone is much, much, much more secure than u2fzero. You're also insisting that your particular use case for needing a backup is the only and best use case. If you want to design a system for your individual desire and needs, that's great, but this doesn't generalize. I'm guessing most people will not want their device baseline to be insecure so that they can have a 2nd insecure backup at hand. As I hinted, the best solution is likely a cloud based token. This can be simulated with u2fzero by using a method similar to what @ecesena proposed. With either knowledge of an authorized external transport key, or by sharing a transport key, the atecc508a can share key material securely. I won't work out the details here, but basically you just need a single initialization-time secret that you store in the cloud. With that, you can take an arbitrary fresh unprogrammed u2fzero and initialize it to look like the one you lost. It has to be done this way (at user's direct control) because if you buy u2fzero's pre-programmed all security is lost. The secret blob can be stored on your [secure] phone and backed up in a safe on a piece of paper, or any other storage scheme which a particular user may require to meet their needs. Personally, I would store it in icloud. or if you used publickey, closer to @ecesena's proposal, you don't need to keep a secret. (at the expense of having to prepare the backup devices ahead of time.)

dimonomid 8y ago
I apologize for being inconsistent in my arguing; indeed, I "switch tack". That's because it's actually hard for me to constantly keep the full picture in my head, and sometimes I start thinking like "omg what I've done it's so insecure", but then realize that I already thought about it and still decided to use that strategy because of this, this and this. In fact I really appreciate you explaining all these details, and to be honest I need to find a decent amount of time to fully wrap my head around it; hopefully on the weekend I'll be able to. I doubt it will change my reasoning about my personal use case, but learning something new about security is never bad. Thanks for that! Hopefully I'll get back to you after learning more. Also wanted to make 100% sure: are you arguing just about the u2f-zero being insecurely implemented, or the whole concept of backup with the cloned and securely-stored token also being bad? If we imagine that e.g. yubico starts producing matched pairs of tokens (I doubt it would, but still let's imagine), primary and backup with the boosted counter, which are implemented securely enough etc - would it be still bad in your opinion?
- jiveturkey 8y ago
  Diagrams help me. They do wonders to organize the thought process down to the most core ideas and cement it in your mind. I have planned to try "mind mapper" software to help with it but haven't done so yet. If you produce some kind of diagram I would be happy to review it with you. > are you arguing just about the u2f-zero being insecurely implemented, yes. the concept of a pre-cloned token is a good one. my main point of contention with you is that in your threat model, a lost phone is a security problem, yet a lost u2f is not. you need to revise your threat model or revise your solution.
  - dimonomid 8y ago
    > my main point of contention with you is that in your threat model, a lost phone is a security problem, yet a lost u2f is not I realized that I could explain my concerns better in the article. My biggest issue with the phone is not that it could get hacked, but that I could just lose it together with my u2f token (because, you know, I always carry both phone and u2f token), and thus get myself locked out of my accounts. So it's not about somebody attacking me specifically to get my 2fa data, but just about some bad luck happening which results in losing both u2f token and a phone which was a backup for u2f token. Instead of Google Authenticator we could use Authy, which synchronizes its database with the server, but Authy account could be recovered with SMS, which is anything but secure. I actually updated the article just now with that point. I really want having a backup which is rock-solid secure and reliable, you know, more reliable than any other 2nd factor I have. So having a token bricked into the wall or something like that would work. > you need to revise your threat model or revise your solution When I have a chance to reimplement the same backup concept having something more secure than u2f-zero, then yeah I surely will revise the solution.

jiveturkey 8y ago

> MCU which does have code protection http://www.break-ic.com/ http://www.break-ic.com/ in short, MCUs are not secure devices. the additional protection is great for surface level protection, and certainly sufficient for most threat models. but in this case, we are talking about an authentication token that is obligated to keep secrets. one cannot claim "secure implementation" without secure key storage. even the atecc508a doesn't really meet the definition of secure. eg, there is no eal certification. no reputable vendor would use it in a commercial security device. it's great for its target market though. unfortunately, there is no way for a hobbyist to acquire actually secure chips. something like the atecc508a will have to do.

jiveturkey 8y ago
although, for this implementation, you don't need to read out the chip anyway. you can just sniff the i2c bus to learn the keys.
- dimonomid 8y ago
  > you can just sniff the i2c bus to learn the keys RMASK and WMASK, which smelled not useful to you, are there exactly to prevent this from happening.
  - jiveturkey 8y ago
    lol no. this is almost not even worth a response. the key managed here https://github.com/conorpp/u2f-zero/blob/master/firmware/src/u2f_atecc.c#L278 https://github.com/conorpp/u2f-zero/blob/master/firmware/src... and here https://github.com/conorpp/u2f-zero/blob/master/firmware/src/u2f_atecc.c#L208 https://github.com/conorpp/u2f-zero/blob/master/firmware/src... just means that the "actual key" (unmasked) only lives in MCU memory for a short time -- the time from when the mask is applied and then until return to caller and memory is cleared, in the enrollment case I linked. In the authenticate case, it lives quite a bit longer because the stack space used for key storage isn't zero'd. The atecc508 doesn't use or know how to use the mask. The actual key used for the encryption is passed in the clear over i2c. (note that the key derivation you suggest is wrong because of the extra xor masking.)