Schneier on Security

Clive Robinson • December 15, 2010 6:57 AM

I would encorage everybody to download and learn the tools not just because they can do forensics but because most of them can also be used for other things such as finding things in memory and hard drives that should not be there which many AV tools cannot do and to help put systems back together again.

But on the forensics side the more you know the less chance you have of been “bull541ted” by LEO’s and their “guns for hire” who use propriatry tools badly after just one two day training course.

I have sat on the side lines of courts hearing “court recognised Expert Witnesses” for the prosecution troting out a mixture of half truths and down right lies “because that’s what the tool and the training taught them”.

The sad reality is these people are not experts they are often LEO’s etc who are not exactly on the fast track through life trying to carve out a job security niche…

The more you know the more you can employe the process of evoloution on the usless lot.

What would also be nice is jurisdiction by jurisdiction guides to the laws of evidence and civil and criminal procedure rules that are in place there.

The Law of the UK with regards evidence is a compleat and utter mess with bit’s tacked on here and there with exceptions and overriders and all sorts of other twists. So much so that most judges and Barristers don’t even know the half of it.

You see this all the time with warrants that are issued illegaly and used by various quasi legal organisations effectivly purjuring themselves infront of judges and magistrates but getting away with it because they can bambozal m’learned bretherin then going on to breach UK&EU data protection legislation (The UK’s OfCom out of their Birmingham office has been a major offender in this regard).

Clive Robinson • December 16, 2010 1:06 AM

@ BF Skinner, Gabriel,

“FBI ‘planted backdoor’ in OpenBSD”

Just for arguments sake I’m going to play the “cough cough male bovine excrement cough cough” card on Mr Perry’s claims.

But also assume that they are taken seriously (they have. to for credability reasons) and another much more indepth code audit takes place on the “giffted” IPSEC stack used on Open BSD.

A couple of questions arise,

1, Will anything be found?
2, Would a real back door be found?

To which the answers are “Yes” and “Probably not”.

As you are probably both aware I have mentione three areas of attack that the likes of the NSA et al would be using these days,

1, Protocol issues.
2, Side channel issues.
3, ‘Known Plain Text’ issues.

There are enough of these that we know that you don’t have to try very hard to find bugs in code to excersise them (think SSL for protocol, AES for side channel, MS format docs for known plain text). We also know that even where ‘bugs’ are known for compatability reasons they are darn difficult to resolve (think Wifi in it’s various and still broken but in use forms). So I’m fairly confident that they are going to find quite a few things if the do an indepth right through the IPSEC audit (including finding protocol bugs in IPSEC).

Would they find a specificaly planted ‘bug’, the answer is ‘probably not’ for various reasons.

Firstly as I’ve mentioned several times before there are so many subtal ways of doing it that you are not likley to spot even a very small percentage. Especialy if the fundemental attack vector is unknown to you.

For instance getting access to the key can be done as I’ve indicated in the past using malloc and friends. A simple example being not using free, but this is fairly well known and memory leak tools will probably pick it up. You can also use malloc and free and then malloc again to get the same block of memory under the new pointer, this is less well known and as it is a correct ‘valid usage’ of malloc it is not something a tool is going to explicitly flag up though it would not be to hard to write a tool to show real memory reuse within a process.

But importantly there are many further variations that are very subtle and in many ways quite stable due to the use of kernel internals virtual memory manager and the MMU. Such tricks can be worked through automatic paging mechanisms, IPC and buffers etc.

It is the usage of memory paging at the hardware level that gives rise to the three academicaly known classes of “cache” attacks.

As we know “loop unrolling” was the first such attack against AES and demonstrated across the network within a few months of AES getting the stamp of approval. We also know that the NSA certifies AES for some Inline Media Encryptors (IME’s) but with the caveat of “only with data at rest”… I’ve made both these points several times in the past.

The reason AES is susceptible to this is a failure to consider this attack vector during the selection process and this makes it a fundemental weakness just like many protocol errors.

BUT this is just one asspect of “getting the key” you don’t have to leak the whole key to get the rest of it with a little work…

And this is the point all encryption systems leak information in one way or another, thus two further questions arise,

3, Can the leak be seen?
4, Is what is leaked usable by an attacker?

Now I can safely say that you can only see what you are looking for, unless your attention is drawn to it in some way. So leak finding is probabilistic in nature (as most things are).

Likewise even if you can see a leak can you recognise what is being leaked is harmfull, and the answer is no you cannot.

For instance black box testing can see ‘noise’ but you cannot tell if there is a real signal in the noise in some way this is part of the well known “Low probability of detect” radio systems that moved into digital watermarking etc.

If you look at the work of Adam Young and Moti Yung with Cryptovirology they show a way that public key systems can have information hidden in them that can be used to break the private key out. They likewise show how you can use PK systems to secure information leakage.

This means that you could put a backdoor into encryption systems whereby you leak the key but as it is encrypted via PK technology you are the only pearson who can make use of the leak…

Which as a consiquence means if PK is secure you cannot corelate any leaked information back to the key, thus black box testing won’t help…

Clive Robinson • December 16, 2010 2:55 AM

@ Carl,

“Commenters on Bruce’s posts always seem to figure out a way to take the post and use it to slam… …anyone in a position of authority.. why?”

That’s an overly obvious question and one most teenagers can answer…

The more authority you have the easier it is to abuse the implicit trust that goes with it.

As has been said many times to be trustworthy you have to be responsible in your actions.

Thus those who are not responsable in their actions would normaly suffer the consiquences via societies justice process.

However as has been repeatedly shown if you have sufficient authority you can game the system not just for you but for others and this gives you further power. Thus you and your friends can evade the justice process.

It’s why we say power corupts and absolute power corupts absolutly…