4 ms·

> 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 gr

> 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.)
    - conorpp 8y ago
      This is a bit late, but the atecc508 does apply a random mask, see PrivWrite command in datasheet. http://ww1.microchip.com/downloads/en/DeviceDoc/20005927A.pdf http://ww1.microchip.com/downloads/en/DeviceDoc/20005927A.pd...
    - deleted 8y ago
      [deleted]
- dimonomid 8y ago
  > in short, MCUs are not secure devices I doubt there is 100% secure device, you know, it's all about tradeoffs. Given enough time and resources, nearly anything can be hacked. By the way, if an attacker has gained physical access to the primary token (and also to the another factor, a password, since token on its own is not too helpful), they don't need to hack it in any way: they can just use it to log into the account, add some other token and revoke the existing one.
  - jiveturkey 8y ago
    > I doubt there is 100% secure device, you might want to read up on EAL certification. Yes, there is no 100% secure device, but "secure" is about resistance to attack and an actual secure element is very resistant, as well as tamper evident. u2f-zero could be hacked in 10s flat if you prep ahead of time. > if an attacker has gained physical access to the primary token ... they don't need to hack it in any way but they need long term access. with this device, short term access is enough to learn the key and then i can get access at a time of my choosing. i can also learn the counter value and you won't notice that i have gained access.
    - conorpp 8y ago
      Yes using a normal MCU for U2F is a bit of a compromise since EAL chips are unobtainium. So flash read protection is the main barrier to physical cloning methods. I'm not sure of any methods to bypass the read protection on normal MCUs in a 10s "drive by" attack. AFAIK, the special companies that provide flash readout (http://www.break-ic.com/ http://www.break-ic.com/), do so by decapping the chip and using involved imaging techniques. I suspect they get good at identifying various flash technologies, many of which are common to many chips. But don't think it's feasible for a drive by. The I2C eavesdropping shouldn't be an issue because the ATECC508A does apply a mask.
    - dimonomid 8y ago
      > you won't notice that i have gained access. If I lose my primary token, how can I not notice that? I look at it a few times per day, and I use it not rarely either, so I can't see how I can not notice if I lose it (even if it was replaced by the similarly-looking device).

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.)
  - conorpp 8y ago
    This is a bit late, but the atecc508 does apply a random mask, see PrivWrite command in datasheet. http://ww1.microchip.com/downloads/en/DeviceDoc/20005927A.pdf http://ww1.microchip.com/downloads/en/DeviceDoc/20005927A.pd...
  - deleted 8y ago
    [deleted]
dimonomid 8y ago
> in short, MCUs are not secure devices I doubt there is 100% secure device, you know, it's all about tradeoffs. Given enough time and resources, nearly anything can be hacked. By the way, if an attacker has gained physical access to the primary token (and also to the another factor, a password, since token on its own is not too helpful), they don't need to hack it in any way: they can just use it to log into the account, add some other token and revoke the existing one.
- jiveturkey 8y ago
  > I doubt there is 100% secure device, you might want to read up on EAL certification. Yes, there is no 100% secure device, but "secure" is about resistance to attack and an actual secure element is very resistant, as well as tamper evident. u2f-zero could be hacked in 10s flat if you prep ahead of time. > if an attacker has gained physical access to the primary token ... they don't need to hack it in any way but they need long term access. with this device, short term access is enough to learn the key and then i can get access at a time of my choosing. i can also learn the counter value and you won't notice that i have gained access.
  - conorpp 8y ago
    Yes using a normal MCU for U2F is a bit of a compromise since EAL chips are unobtainium. So flash read protection is the main barrier to physical cloning methods. I'm not sure of any methods to bypass the read protection on normal MCUs in a 10s "drive by" attack. AFAIK, the special companies that provide flash readout (http://www.break-ic.com/ http://www.break-ic.com/), do so by decapping the chip and using involved imaging techniques. I suspect they get good at identifying various flash technologies, many of which are common to many chips. But don't think it's feasible for a drive by. The I2C eavesdropping shouldn't be an issue because the ATECC508A does apply a mask.
  - dimonomid 8y ago
    > you won't notice that i have gained access. If I lose my primary token, how can I not notice that? I look at it a few times per day, and I use it not rarely either, so I can't see how I can not notice if I lose it (even if it was replaced by the similarly-looking device).