4 ms·

> I generally tend to think that an attacker with hardware access will compromise that hardware sooner or later, and you should design your security measures ar

by als0 6y ago

> I generally tend to think that an attacker with hardware access will compromise that hardware sooner or later, and you should design your security measures around that assumption. There are two types of hardware attackers. Those who have home tools and those who have access to lab equipment. Unless you're designing a smartcard, you're only going to have the budget to protect against the former.

MayeulC 6y ago
But you can't guarantee that the security won't be broken in 30 years, when we have another infineon-class fiasco (https://nvd.nist.gov/vuln/detail/CVE-2017-15361 https://nvd.nist.gov/vuln/detail/CVE-2017-15361 I think), or in 300 years when you'll be able to buy nanites by the kilogram at the convenience store. It seems obvious (I hope) that you can't protect that kind of technology against secret leakage on these timescales. I think it's wishful thinking that the technology you are relying on won't be broken in a one-year timeframe. Unlikely, I agree, but that happens, and you just hope that it will be someone else's tech, not the one you rely on to keep your secrets. The only practical measure you can take at that point is buying insurance :) So, in any case, you have to make sure the secrets you are storing in HW aren't too important, and can be rotated easily. I would add a third kind of hardware attacks class to your list, which is the one I think justifies these developments: the kind that can be performed by an evil maid. No shutdown, 30s to 2 hours to perform the attack, on-site. Luckily, it's rather easy to protect against that (a solid case would).
- als0 6y ago
  You can't guarantee security of anything, ever. But that doesn't mean you shouldn't try to prevent attacks. Of course timescales and assets are important. For the movie streaming industry, it's a certain number of months before and after a stream is publicly released. After sales have been made, there are diminishing returns when trying to protect the content. > I think it's wishful thinking that the technology you are relying on won't be broken in a one-year timeframe It depends on what your assets are, your threat coverage and who you are trying to protect against. Some people are successful at doing this for more than a year's timeframe, which is enough to be overall successful. If you're developing something as popular and precious as an iPhone, it's far more challenging. Nothing lasts years. The economical side of security is always to reduce the likelihood and impact of threats until they aren't worth worrying about.
- a1369209993 6y ago
  > But you can't guarantee that the security won't be broken in 30 years Yes, you can. Easily, relative to what you already need to protect against physical tampering today. Include a real time clock, and a comparator that, after 29 years, sets off the anti-tampering magnesium/thermite/whatever charge to destroy your data storage. In fact, you probably don't even need the comparator as such; just use a carry bit from the RTC. Guaranteeing that the security won't be broken in less than 30 years (really, less than X years for whatever X you set the self-destruct to) is the hard part.

by als0 6y ago

MayeulC 6y ago

But you can't guarantee that the security won't be broken in 30 years, when we have another infineon-class fiasco (https://nvd.nist.gov/vuln/detail/CVE-2017-15361 https://nvd.nist.gov/vuln/detail/CVE-2017-15361 I think), or in 300 years when you'll be able to buy nanites by the kilogram at the convenience store. It seems obvious (I hope) that you can't protect that kind of technology against secret leakage on these timescales. I think it's wishful thinking that the technology you are relying on won't be broken in a one-year timeframe. Unlikely, I agree, but that happens, and you just hope that it will be someone else's tech, not the one you rely on to keep your secrets. The only practical measure you can take at that point is buying insurance :) So, in any case, you have to make sure the secrets you are storing in HW aren't too important, and can be rotated easily. I would add a third kind of hardware attacks class to your list, which is the one I think justifies these developments: the kind that can be performed by an evil maid. No shutdown, 30s to 2 hours to perform the attack, on-site. Luckily, it's rather easy to protect against that (a solid case would).

als0 6y ago
You can't guarantee security of anything, ever. But that doesn't mean you shouldn't try to prevent attacks. Of course timescales and assets are important. For the movie streaming industry, it's a certain number of months before and after a stream is publicly released. After sales have been made, there are diminishing returns when trying to protect the content. > I think it's wishful thinking that the technology you are relying on won't be broken in a one-year timeframe It depends on what your assets are, your threat coverage and who you are trying to protect against. Some people are successful at doing this for more than a year's timeframe, which is enough to be overall successful. If you're developing something as popular and precious as an iPhone, it's far more challenging. Nothing lasts years. The economical side of security is always to reduce the likelihood and impact of threats until they aren't worth worrying about.
a1369209993 6y ago
> But you can't guarantee that the security won't be broken in 30 years Yes, you can. Easily, relative to what you already need to protect against physical tampering today. Include a real time clock, and a comparator that, after 29 years, sets off the anti-tampering magnesium/thermite/whatever charge to destroy your data storage. In fact, you probably don't even need the comparator as such; just use a carry bit from the RTC. Guaranteeing that the security won't be broken in less than 30 years (really, less than X years for whatever X you set the self-destruct to) is the hard part.