Re: [PATCH resend][CRYPTO]: RSA algorithm patch

["Indan Zupancic" <indan@nul.nu>]

On Thu, April 12, 2007 10:34, Tasos Parisinos wrote:
> I didn't have time to read the pdf but i will. As for erasing ram it usually means to also
> scramble it and there are chips that advertise that can do this in 1 cycle. Well reaching the bus
> or ram
> to probe it is another thing. Most die in such chip are also hidden under protective meshes so it
> takes some time.

Those can be peeled off. But the paper I linked to concentrates on other kinds of attacks.

Quote:

"One of the main contributions of this thesis is fault injection attacks done in a semi-invasive
manner which can be used to modify the contents of SRAM and change the state of any
individual transistor inside the chip. That gives almost unlimited capabilities to the attacker in
getting control over the chip operation and abusing the protection mechanism.
Compared to non-invasive attacks, semi-invasive attacks are harder to implement as they
require decapsulation of the chip. However, very much less expensive equipment is needed than
for invasive attacks. These attacks can be performed in a reasonably short period of time. Also
they are scalable to a certain extent, and the skills and knowledge required to perform them can
be easily and quickly acquired. Some of these attacks, such as an exhaustive search for a"

It gives a good overview of all kind of other attacks and defences too. Personally I find the
non-invasive attacks the most interesting. (The pdf is 12 MB, for the low bandwidthers.)


> What you said is true, systems are created and broken, the question is what
> you have to hide and whether the person that wants to break it has the money the will the
> knowledge and the equipment
> to do it. Because if he is to spend a million euro only to create fraud of half a million euro
> then he wont do it.
> That has to do with risk management.

Very true, and the right way to look at it. (Vendors should say "it costs about $X to
break this chip", instead of saying that it's secure, and then not giving guarantees.)


> I understand and i agree, thing is that i dont decide about which parts are given GPL.

No, the kernel licence and others do. But you can't edit the kernel and distribute it without
releasing those modifications under the GPL.


> people think that by hiding implementations (which can be reverse engineered of course)
> will make it more difficult to break. Well i agree with you but... its not in my hands.
> So i will come back with these parts replaced with some of my own

What else is there except the signing and binary loading hooks? Perhaps some caching, but
not much more, is there? I'm a bit baffled about what's kept hidden here, as there doesn't
seem much to hide, except perhaps other, independent "protections", but we weren't talking
about those.

I don't know anything about your company, but I bet the marketing people are more in
favour to keeping it hidden than the security people. I'd ask the legal people for the
kernel parts though.


> And a question
> Can someone provide me with a full list of kernel functions where code is loaded?

Counter questions:

- Why should we give that list if you're not going to release the code you're going to write?
Or in other words, why should we help you?
(But if you're going to open it up, try to find people interested in the same functionality so
you can work together on it. Not me, I'm just a passer-by.)

- That you ask for that list implies that you're not going to audit the whole kernel source
for such functions. That might imply, to some, that your security code isn't as secure as it
should be. People make mistakes, forget things, so on. Both you and people providing a list.
And such mistakes are easiest spotted when more people look at the code. But that's not
possible when the code is hidden. Then only the ones with malicious intents keep looking. So
perhaps it's harder to spot deficiencies in closed source protection code, but it will probably
have more of it too. Your choice, you take the risk.

Greetings,

Indan


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/