| 1 |
Hi! |
| 2 |
|
| 3 |
On Tue, 21 Aug 2018 09:42:28 -0400 Rich Freeman wrote: |
| 4 |
> On Mon, Aug 20, 2018 at 7:26 PM Andrew Savchenko <bircoph@g.o> wrote: |
| 5 |
> > |
| 6 |
> > No, it doesn't. The cost of extracting a key from a stolen token is |
| 7 |
> > approximately $1000 depending on a token model. |
| 8 |
> > |
| 9 |
> |
| 10 |
> I'll have to ask for a citation on that one. |
| 11 |
|
| 12 |
Fine. |
| 13 |
|
| 14 |
First and foremost source is already available from web archive |
| 15 |
only: |
| 16 |
https://web.archive.org/web/20180710200252/https://community.st.com/thread/46432-hacking-readout-protection-on-stm32 |
| 17 |
|
| 18 |
Some technical details: |
| 19 |
https://www.aisec.fraunhofer.de/en/FirmwareProtection.html |
| 20 |
|
| 21 |
Some services and prises: |
| 22 |
http://www.ic-cracker.com/ |
| 23 |
http://www.unlock-ic.com/ |
| 24 |
https://russiansemiresearch.com/en/service/#read_prot |
| 25 |
|
| 26 |
It doesn't matter if chips inside some tokens are not on the list |
| 27 |
above, this is the industry wide problem. Physically there is no |
| 28 |
such device as read protected memory cell. Only technological size |
| 29 |
of the cell provides some minimal protection: it is easier to read |
| 30 |
500 nm cell than 20 nm. That's all. No further protection is or may |
| 31 |
be available. |
| 32 |
|
| 33 |
Furthermore I hope you understand that not all information is |
| 34 |
available via clearnet links and not everything is disclosured on |
| 35 |
the net due to NDA or similar agreements. The real state of matter |
| 36 |
is much worse than in the links above and industry for reading |
| 37 |
"protected" devices is well established, growing and affordable. |
| 38 |
|
| 39 |
The only possible way to protect from such attacks is not to store |
| 40 |
unencrypted key material on token at all, e.g. have it password |
| 41 |
protected, temporary save unencrypted bits only in RAM and guarantee |
| 42 |
that RAM cells and all aux registers will be securely wiped out |
| 43 |
without any residual storage after its usage. I don't know such |
| 44 |
devices though, since all of them rely on principle "one can't read |
| 45 |
bits from our storage". |
| 46 |
|
| 47 |
> I think the satellite TV industry did quite a bit to make hardware |
| 48 |
> tokens VERY resistant to tampering. |
| 49 |
|
| 50 |
Sorry what? Satellite TV is quite trivial to break without any |
| 51 |
preacquired tokens at all. Its encryption is busted by design. |
| 52 |
|
| 53 |
> Maybe a few state actors could |
| 54 |
> defeat them, but if Chinese intelligence needed to infiltrate us I'm |
| 55 |
> sure they'd figure out a way to do it. The NSA probably has a hard |
| 56 |
> enough time keeping them out of stuff. |
| 57 |
|
| 58 |
Ha-ha. As Mr. Snowden have shown NSA can't even control its own |
| 59 |
data. |
| 60 |
|
| 61 |
> IMO the main threat model for Gentoo is the script kiddie who wants to |
| 62 |
> stick rm -rf / in all our ebuilds, and actually knows how to do it |
| 63 |
> correctly. Unless we move to a model that has much more sophisticated |
| 64 |
> QA (release-based, peer-review, CI, etc) we're not going to be defeat |
| 65 |
> more complex attacks, because right now any Gentoo dev with commit |
| 66 |
> access can basically do whatever they want, and becoming a dev isn't |
| 67 |
> that hard for somebody who is determined. |
| 68 |
|
| 69 |
IMO you are trying to mix technical and social problems here. Indeed |
| 70 |
determined individual may infiltrate any free software organization |
| 71 |
accepting new members (or buy some long-term developer, or force |
| 72 |
them via some secret court gag order), but an impact from such |
| 73 |
infiltration will be likely limited to a single attack which will |
| 74 |
result in administrative (e.g. kicking out) and possibly legal |
| 75 |
action and preparation for such attack will require too much time |
| 76 |
and money, so gain-to-effort ratio will be quite low. |
| 77 |
|
| 78 |
> I'm not saying that tokens are uber-powerful or that they're a waste. |
| 79 |
> They have some pros/cons. On the whole they're probably a good idea, |
| 80 |
> but honestly the fact that devs are going to have to pay to return |
| 81 |
> them/etc limits their value, especially since the whole openpgp |
| 82 |
> smartcard standard already limits their utility quite a bit, and key |
| 83 |
> recovery is still a tricky problem for orgs where people don't |
| 84 |
> routinely see each other in person or at least know each other by |
| 85 |
> voice. |
| 86 |
|
| 87 |
I fully agree that tokens are just another layer of security. But |
| 88 |
sometimes additional security layers reduce practical security due |
| 89 |
to social effects: e.g. cyclist wearing good helmets and other |
| 90 |
protection are inclined to more dangerous driving since they have |
| 91 |
a false sense of being secure in a good helmet. The same with |
| 92 |
hardware tokens: their users are often less careful with other |
| 93 |
measures like password hygiene or strength because they imply they |
| 94 |
are well protected by a token already. |
| 95 |
|
| 96 |
Best regards, |
| 97 |
Andrew Savchenko |
Archives