Slashdot Mirror

http://www.schneier.com/passsafe.html

Password Safe. Works great. You could just install on your USB fob, I imagine.

Password safe is awesome
http://sourceforge.net/projects/passwordsafe/

Bruce Schneier recomends it in many/most of his monthly crypt-o-grams
http://www.schneier.com/

Insurance companies will not honour your home insurance or car insurance policy in the event you left your car unlocked and it was stolen.

This is why insurance companies are now looking at how they insure around the liability with regards to the operating system companies use and efforts that have been made to secure infrastructure. Bruce Schneier has discussed the insurance and network security issue often, like here.

The onus still lies on the end user to make the effort to secure their asset. And the criminal will still be charged with unlawfull entry, but the insurance industry will use lack of effort on the owner's part as an out to not pay out on the policy.

The mobile networks are disabled to public numbers, to prevent remote detonation.

A very common misinterpretation. In emergencies, mobile networks are reprioritised for emergency workers, at the expense of ordinary people and (one might say especially) journalists.

See Crypto-Gram: February 15, 2005 - Comments From Readers - Shutting Down the GPS/Cell Network. Scroll down a bit.

On the other hand, if thieves think will get busted by stealing laptops, this helps everyone. Schneier has an interesting note on his blog about lo jacks in cars benefiting everyone.

> I'd have thought the motivation was to limit the number of separate accounts you need.

Yes, log in once to the network and browse on all partner sites without having to log in again.

> Having a billion accounts running around is a massive security nightmare.

Quite the contrary. Having a single point of failure (master account) is much worse.

> Either you're using the same password everywhere

The only way is to educate users about pass phrases and password schemes. Most people who are reading this probably have 3-4 passwords which they use for different sites depending on the security threat. My bank account sites for example all have exclusive passwords. My social software (msn, orkut friendster) have the same password. If you really must, devise a password scheme based on domain name. If your regular pass for example, is mhallwfwwas! (mary had a little lamb whose fleece was white as snow!), then for orkut.com you can use mhallwfwwasou (append all vowels (O and U) in the domain name OrkUt to your password. You can get more creative by appending vowels in reverse order or by interspersing: mOhUallwfwwas, using alternate casing etc).

> (and telling every web site owner your password)

This is a real threat. You have no guarantee that the site owner isn't privvy to your password. This is more an issue of trust than security and in that the proposed system does add some value provided their central servers can be trusted. If you used a password scheme as outlined above, the website owner would not be able to extract mhallwfwwas from mohuallwfwwas (assuming the passphrase does not make sense to him) rendering that password useless to him/her.

Like I said, it's about educating users. I am other geeks have their own set of password'ing rules.

> or you're wandering around with a notebook of thousands of passwords.

Get Password Safe. You may argue that this results in a master password but the software is localized so the threat is smaller (one person gets hacked at a given time; the hack must be local through a key logger or something which is more or less preventable).

The biometrics biz doesn't want you to know, but biometrics suck.

Even if one were to develop a much better biometric system, there are serious drawbacks. Any biometric key is really just a password that cannot be changed, even if the password has been compromised, or even if the whole system has been cracked wide open.

Suppose someone invents a "foolproof" retinal scanner system, which is deployed at every point-of-sale terminal in the US. All credit card transactions are verified with the retinal scanner. A year later, someone figures out a way to imprint retinal holograms on contact lenses, or finds some other circumvention. Now if someone gets his hands on your retinal data, your financial life is completely hosed, forever, or at least until you convince the powers-that-be to trade in $50 billion worth of retinal scanners for updated models. You can't call the credit card company and ask for a new retina.

As ever, security is really more about attitude than about devices. An awful lot of dollars worth of credit card fraud, for example, would be stopped cold if store clerks bothered to just check the signatures on credit card slips.

These Supremes answered the wrong question. They were asked to validate or repudiate the lower court's opinion. Which was that when Grokster does not promote criminal use, the software has has "substantial legal use", Grokster does not know when an illegal transaction occurs, and Grokster does not even itself have the power to bar a specific person from making a transaction, Grokster cannot be liable for a criminal transaction by a user. And, by extension, neither can any other provider of software meeting those conditions. The lower Grokster decision did not explicitly state that Grokster must not promote criminal use, though that seems implicit in "has substantial legal use", when such a condition is nowhere mentioned explicitly. You know, like how "possession of encryption implies criminal intent".

I suppose that Grokster also must not "force users to commit crimes, including at gunpoint or through hostages or nuclear blackmail", but the Supremes did leave us all thrashing in ignorance of that detail. Likewise, we still can't be sure that Grokster can avoid liability when they do not promote crime, because we can only infer that state - which costs a lot of money for lawyers to do, with Hollywood now making an industry out of propagandizing that implication.

Perhaps the lower court, to which the Supremes' decision returns the case for a new decision with their "advice", will find that Grokster is not liable, because it did not promote criminal use. Then MGM will take the case back to the Supremes (the 2008 remix). And perhaps the Supremes will reject hearing the new case, having heard it already. Then, like the Schiavos, MGM will keep their case under reconsideration for years. Grokster and the rest of us in the lower courts will spend a lot of money defending under this ambiguous ruling, and the entire P2P and streaming industries, not to mention software in general, will operate under the uncertainty that an ax could fall on our necks any June for the next decade. Thanks, you cranky ancient prima donnas with lifetime immunity from accountability! The rest of us have to live with your work for our entire lives, without that guaranteed paycheck. We really spend a lot of money on these Supreme Court justices, for them to produce such a shabby product.

Now, on the heels of that blatantly criminal "eminent domain" ruling, Conservatives will be screaming for new Supremes who "respect property rights" and "hold individuals responsible for their actions". When Bush appoints the most corporate Supremes we can imagine, and puts Clarence Thomas in charge of the court, we'll be stuck with the most corporate court ever, with the most corporate Congress ever, and the most corporate White House possible. Unless Democrats can take back the House and Senate next year, and deliver at least some of the competition with teeth that checks and balances our mechanical government, this country is doomed. And everyone else within its reach - which means everyone else. Funny how that particular blockbuster movie won't be coming out of MGM studios this Summer.

And the Feds have already got their precedent that "encryption possession proves criminal intent". That old "less intrusive government" Republican Party has tightened the noose around the bedroom, the keyboard, the sidewalk, the hospital. Hello, Big Brother - you look just like George Bush.

>BitTorrent already hashes the download with SHA1, so unless the Spyware
> industry has come up with some practical way to generate
> collisions it's not the pieces that are corrupt. It's the whole
> torrent.

I'm glad you asked me that, Brian.

Hmmm... Obviously I'm not a US citizen, but it seems that not everyone feels that way. In fact it looks like the US already has their Real ID bill passed, and not everyone welcomed it with open arms.

All the things you mention are abhorrant, but none of them have anything to do with a national ID card. The police can stop you and ask for your papers today in most states. A national ID card won't change that at all. The rules for how the police act are totally seperate from the rules on what constitutes a valid ID.

Fair points and I'll try and address them.

"but none of them have anything to do with a national ID card". They do however have to do with how the ID card is being sold to the british public. The Id card is being touted as, among other fairy tales, a panacea against terrorism. And yet, as pointed out by an ancestor post, that id is useless unless checked, and to check them widely and efficiently would require measures similar to the ones I describe.

"The police can stop you and ask for your papers today in most states". But if the card is to have any hope of serving its alleged purpose this would need to be endemic. There were checkpoints like this set up in Northern Ireland during the height of the Troubles. I understand that everyone there thought they were a Bad Thing. I sometimes wonder how many of those who say "Harumph! ID cards! Jolly Good Thing Too!" have actually thought through the implications, or whether they would be so keen if they had. Of course, everyone always assumes that they won't be on the receiving end.

"The rules for how the police act are totally seperate from the rules on what constitutes a valid ID". Arguably perhaps, but for the cards to work as advertised... well I've done that bit. The question is whether the government is planning such repressive measures, or whether they're lying about the cards effectveness whilst harbouring ulterior motives, or whether they are just plain incompetant.

Let me give you a little background here. The UK is the most heavily surveilled nation on the planet. Recent legislation saw the right to silence of an accused criminal removed. We have curfews in some parts of the country now - only for certain age groups at the moment, but that can quickly change. We have travel restrictions; usually applied in cases of overseas football matches but again the mechanism is there and is not limited to football hooliganism. Now they want to remove the right to a trial by jury. Oh and resign from the charter for human rights as well.

The last journalist to seriously embarrass the government was sacked, along with the director general of the BBC, while the whistle blower in the case was hounded to his grave.

Does anyone else see a trend developing here?

Almost all of the above is the work of the current government. I hope you'll excuse me if I don't fall over myself in my haste to extend them the benefit of the doubt.

What exactly is the downside to having ID standards that are harder to fake?

ID standards and implementations (in the non-code sense of the word) are not the same thing. Let's not confuse matters unnecessarily. My privacy in only violated by the government when the government forces me to present an ID.

And I've already explained why I find this less than reassuring. All the same, I think we're losing sight of something fundamental here:

The single best reason why we in the UK should not have ID cards is that we do not want them. We live in a dem

I don't understand why Slashdot (a place I like to think of being pretty well grounded in approaches to technology reviews) has gotten caught up in this blog nonsense. Blogs are not news.

Just because it's content posted in a blog doesn't mean it's not news, or not reliable. Should I avoid reading what Bruce Schneier has to say just because he posts it in a blog? Or maybe I should wait until next month for him to release his Cryptogram where he basically reposts the same stuff?

Like any other source, you have to evaluate it based on its merits. But dismissing it out of hand because it's a blog is silly.

Jason.

SHA-1 apparently has the same kinds of weaknesses.

I don't that is exactly true.

From http://www.schneier.com/blog/archives/2005/02/sha1 _broken.html:

"collisions in the the full SHA-1 in 2**69 hash operations, much less than the brute-force attack of 2**80 operations based on the hash length."

2**69 is still a very large number, so you probably shouldn't be worried just yet. It isn't quite the same as the bit trick for MD5. If anyone knows of a bigger weakness in SHA-1, I would be interested to know.

Here's a short article Bruce Schneier wrote on how to become a cryptographer (as a civilian): http://www.schneier.com/crypto-gram-9910.html

Other attacks on MD5

in my next big project?

In all seriousness, I believe Schneier's right. We need a competition for a new hash function.

Nah, let's just wait for 24 to drop the words "MD5" before we know it's really bad.

See Schneier's Blog for more thoughts on the subject. I am sure it will get fleshed out more as more details emerge.

Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to suffering.
--Yoda

I've used PasswordSafe for a years now and haven't had any trouble with it at all. PasswordSafe was originally written by Bruce Schneier, the oft-quoted security expert. It's now open source and has picked up some nice functionality. From Schneier's web site:

"Password Safe protects passwords with the Blowfish encryption algorithm, a fast, free alternative to DES. The program's security has been thoroughly verified by Counterpane Labs under the supervision of Bruce Schneier, author of Applied Cryptography and creator of the Blowfish algorithm."

Bruce Schniers (now Open Source) App:

Password Safe

Is exactly what you need to "write down" passwords with. You only need remember a single password to decrypt the database. And since the database uses Blowfish, it is pretty damn good.

I have over 50 username/password combos stored in mine with a strong password to open the database itself.

If you need to write down a password, this is the way to do it.

Bruce Schneier also reccommends this - see this and scroll down to the paragraph on passwords. I actually use GPass, which I like a lot. I remember one long random password and make sure to back up my data file to a second hard drive. The ability to copy usernames and passwords to the system clipboard is nifty.

http://www.schneier.com/passsafe.html

Password Safe for Windows is supposed to be decent

May 2001 Crypto-gram

Bruce Schneier's Password Safe.

The major problem is that Unicode simply can not be made secure. So any measure is going to have to be more social than technical.
http://www.schneier.com/blog/archives/2005/02/unic ode_url_hac_1.html

Some comments: I haven't read Beyond Fear yet, but I have read Applied Cryptography. The San Francisco Public Library kept it in a back room and asked me to surrender my ID to look at it. I have no idea why. Maybe it's a terrorism manual.

Secure file transfer is a solved problem. There are several options available for secure file transfer which don't require any more coding than a simple shell script -- scp, sftp, nfs or rsync over an ssh tunnel, etc. You can easily replicate a relational database in real time over an encrypted channel using a VPN.

Even if you require a custom solution, you don't need to implement your own encryption algorithms -- there are open-source crypto libraries available for virtually every language and operating system imaginable. Not only is reinventing the wheel foolish, when you're talking about cryptosystems, it's downright dangerous.

Suitcase nukes exist, sort of. While it's not quite something you'd carry in a suitcase, the Special Atomic Demolition Munition was a 1-kiloton nuke that weighed about 68 kilograms. You're not going to carry it in your suitcase unless you're He-Man, but you could certainly fit into the trunk of your car, even a French one ;) However, the odds of a terrorist group being able to build a nuke this small are fairly minimal without being handed the design by somebody else.

The resources and experience required to build a nuclear weapon are also somewhat less than is commonly believed; this article on the former South African nuclear program gives some idea of the minimum budget required for the job from scratch- tens of millions of dollars, but not hundreds. I should add that I'm highly skeptical that any terrorist group could coordinate this kind of money and people, in secret, for long enough to pull such an accomplishment off.

Finally, uranium, even enriched uranium, or plutonium is pretty hard stuff to detect; they just don't emit very much radiation until you push them into a critical mass! Bruce Schneier's blog links to an extensive report on the topic; he also links to news reports about how the detectors they have bought detect so many false alarms as to be essentially useless. Maybe the three-letter agencies have something better (for instance, looking for chemical traces of radioactive material rather than radiation itself), but if it is it's kept pretty secret.

Still, you're basically right. Terrorists aren't going to be whipping up nukes to send through the mail any time soon.

Suitcase nukes exist, sort of. While it's not quite something you'd carry in a suitcase, the Special Atomic Demolition Munition was a 1-kiloton nuke that weighed about 68 kilograms. You're not going to carry it in your suitcase unless you're He-Man, but you could certainly fit into the trunk of your car, even a French one ;) However, the odds of a terrorist group being able to build a nuke this small are fairly minimal without being handed the design by somebody else.

The resources and experience required to build a nuclear weapon are also somewhat less than is commonly believed; this article on the former South African nuclear program gives some idea of the minimum budget required for the job from scratch- tens of millions of dollars, but not hundreds. I should add that I'm highly skeptical that any terrorist group could coordinate this kind of money and people, in secret, for long enough to pull such an accomplishment off.

Finally, uranium, even enriched uranium, or plutonium is pretty hard stuff to detect; they just don't emit very much radiation until you push them into a critical mass! Bruce Schneier's blog links to an extensive report on the topic; he also links to news reports about how the detectors they have bought detect so many false alarms as to be essentially useless. Maybe the three-letter agencies have something better (for instance, looking for chemical traces of radioactive material rather than radiation itself), but if it is it's kept pretty secret.

Still, you're basically right. Terrorists aren't going to be whipping up nukes to send through the mail any time soon.

Always important to have on board hardware crypto systems that are vulnerable to timing attacks.

I think that a fingerprint counts more as "2) Something you have."

Security risks of biometrics.

Of course, there's Scheier's Password Safe, which is now a SourceForge project. See: http://www.schneier.com/passsafe.html. Works for me... I carry the encrypted file around on USB flash and who cares if I lose it... barring quantum computers, nobody's going to be breaking it within my lifetime.

It's by crypto genius Bruce Schneier, it uses Blowfish, it's open source and if you want that extra measure of security you can compile it yourself. It's for Windows but there are Unix/Linux versions too.

Password Safe

You can't memorize good enough passwords any more, so don't bother. For high-security Web sites such as banks, create long random passwords and write them down. Guard them as you would your cash: i.e., store them in your wallet, etc. Never reuse a password for something you care about. (It's fine to have a single password for low-security sites, such as for newspaper archive access.) Assume that all PINs can be easily broken and plan accordingly. Never type a password you care about, such as for a bank account, into a non-SSL encrypted page. If your bank makes it possible to do that, complain to them. When they tell you that it is OK, don't believe them; they're wrong.

Listen to the low-karma slashdot troll Sheepdot. Sure, he says a lot of obviously wrong things and gets called out on it, and whenever he does he refuses to justify himself and just insults the people who catch him. This is a sure sign of a truly powerful security and voting systems expert.

I mean, what does Bruce Schneier know? The world comes to slashdot trolls for its opinions, after all.

How can anyone fail to sense your hidden genius in your appreciation for half-baked security tools that have a history of failure traceable as far back as Phrack articles from 1993.

Yes, ladies and gentlemen, only on slashdot can a whiny, obnoxious, ignorant baby like Sheepdot treat experts like assholes and still get a free education in return:

--
"More recently, other implementations of LKMs for hiding processes,
files, and directories have come about that can get around the above
described methods of defeating standard root kits, as well as
cryptographic checksumming programs like "tripwire" that must trust the
operating system to present them with valid bits from disc and memory.

The Hacker's Choice (THC) from Germany has write-ups on loadable
kernel modules for Linux, FreeBSD, and Solaris, which describe this
methods of hiding out on a rooted box:

http://www.thehackerschoice.com/papers/LKM_HACKING .html
http://www.thehackerschoice.com/papers/bsdkern.htm l
http://www.thehackerschoice.com/papers/slkm-1.0.ht ml

TESO has another Linux LKM ("adore") along these same lines:

http://www.team-teso.net/releases.php

Using methods such as these, integrity checking programs like "tripwire"
and NIPC's "find_ddos" programs can be subverted, as the kernel could
not even be trusted to give correct results when searching process
tables, network structures, or file systems.

You might think that simply disabling LKM support in the kernel -- which
is still a good idea to improve security on a server whose configuration
will be stable -- is the final answer. Not exactly.

Another method of inserting code into running kernels -- even if LKM
support is not present -- is described by Silvio Cesare:

http://www.big.net.au/~silvio/runtime-kernel-kmem- patching.txt"
--

Too bad you can't run tripwire to protect your brain, Sheep. LOL.

All this hasn't changed your mind? Well, I tried my best.

I feel obligated to advise you that your opinions conflict with those of almost all of the experts who have considered the problem - people much smarter than you and me who have spent their lives focused on these issues. To give you an idea of the caliber of people you're taking on, here's Schneier. So don't just take my word for it.

When discussing rootkit detection, we should be careful not to confuse on-line and off-line detection. Off-line detection (done with a separate machine you believe you trust) can make use of checksums or comparisons as you describe. All I am saying is that on-line detection (the machine inspecting itself) is impossible - because a compromised host can return the "correct" data to its own detection routines. Indeed, any "normal" state can be simulated.

hmmm, I'll be as paranoid as you for a second and claim an essentially undetectable alteration to the printout (via human means) that means the vote is registered in the OCR software differntly than what it 'says' ;-)

I'm intrigued but I don't understand you. How do you propose this would work?

But in most systems right now if the hand recount and machine recount were seriously out of whack it would just invalidate the election.

That's "just" the exact, ideal behavior! The most you can hope for from any other system, paperless, etc. is that it do as well.

I'd feel even better if there were some way of validating the printed ballot in the presence of the voter (no poor print job etc...).

That's exactly what I'm already proposing. The voter does validate it. If the paper doesn't clearly match their intentions (or, for an optical scan, isn't being read properly by the machine) then they signal to the election workers, etc. etc.

They are easy to invalidate (punch a few extra holes, make extra marks),

No, they are not.

For destruction, if you bought 500 sheets of paper, and you end up with 400, you discovered fraud and invalidate the election.

For other forms of invalidation, optical scans that won't scan properly must be redone by the voter to "count," and verified receipts are generated by machine and only exposed to the voter behind glass, so they're basically guaranteed to be valid. If a machine itself generated invalid ones the voters would catch it instantly.

You don't trust code cause you don't trust people.

I don't trust code because its a game that allows untrustworthy people to win vastly more easily. That's really all.

A paperless code based system has the potential to remove people from everything except making the code and inputing the votes.

I have to confess, I have no idea what you mean by this. How can paperless possibly accomplish this? It does not reduce any fallible human involvement, only add vast new amounts of it. Well, maybe I have misunderstood you.

At the end of the day, I think you have to build frameworks that allow people to trust each other, because they make it easy to catch someone breaking the rules.

Hopefully these kids (and those who are following this story) will learn the following lesson:

It doesn't matter how many security holes a system has; never, ever talk about them or try to get them fixed.

Take, for example, the US's Airport "security." That system is a complete joke. I mean, it is not even funny how easy it is to sneak things past the "guards." If you try to point out where the flaws are, they will arrest you.

Remember, their goal is not to provide security, but rather the illusion of security. The unwashed masses need the government to "do something" so they can go on about their little lives without fear. It doesn't matter if that "something" works or not, or how much money is wasted.

The hyperthreading covert information leakage is unlikely to be a problem in Linux since Linux doesn't have true "threads". Each thread is represented by a process and the author states that multiple processes wouldn't be able to use the Processor L1 cache due to process switching overhead.

This exploit also uses a few "small" [sic] bits of handwaving:

1) Ability to syncronize the two separate processes. This was done for the author's example by using a debugger, "spy" to "know" when openssl was started and when it ended (p6).

2) quite another bit of handwaving with "On an otherwise quiescent system" (p6)

3) On a trusted OS, how did "trojans" and "spy" programs get loaded? On such systems, it is usually not the case that even compilers are availabe let alone the ability to load programs on demand.

On a trusted OS, a trojan might, at best, be loaded by a low-level browswer/download process. On a MLS, the user doing the downloading doesn't (or shouldn't) have administrative access to allow a trojan or a spy access to realtime functions like "process debugging", and "process scheduling" (perhaps including the "sched_yield" function.

It is quite likely that on a properly configured MLS system, web browsing would be done at a lowest level of priviledge, where only previously installed programs are allowed to run -- i.e. you can't download a trojan and have it be runnable. Anything downloadable to a writable partition has the "noexec" bit set. This is not user-changeable by a user with Mandatory Access Control's in place (often used with MLS to prevent privilege elevation).

4) It's unlikely that a MLS secure system with MAC (vs. Discretionary Access control, or DAC) would even be hooked up to the internet.

The whole bit describes an unlikely scenario in a MLS(usually MAC) system.

None of this means the author hasn't done his homework and there isn't a risk
of covert channels using this means, but in the real world, super secure systems shouldn't be running code that hasn't been rigorously examined and proven to some "Effective Assurance Level" (EAL).

The whole bit of caching could be extended to the Linux block cache, but in such a scenario, to provide true Level Separation, different priviledge levels likely wouldn't use the same block devices -- and hopefully, Processesors could have a bit as to whether to divide the cache/processor or to allow cache sharing (which would benefit performance for most apps).

Also, I might ask -- how would two different threads of the same process get two different levels of security clearance -- that just seems like dangerous programming and such a program would likely not be approved for most MLS systems.

It is a good paper, and it raises good issues to be aware of, but in practice it doesn't seem easily implemented.

However -- that stated -- there have always been known information leakage problems on multi-user computers. Simply measure latency in key echo's, network pings and program performance. All of these can be used to leak bits of information.

As for getting 310 bits out of 512...who's using 512 byte RSA keys these days? Bruce Schneier, in 1995 listed 1280-2048 bits for an RSA key.

Some symple preventive measures for now: 1) don't allow different threads in same process to have different security levels. 2) don't run untrusted programs on a "secure" system. 3) providing L2 cache separation _might_ be useful for some small number of government users trying to run an MLS on one machine, but it seems it'd be more assurance for them to use two separate processors in two separate machines physically separate machines running at different security levels.

Sorry if I've overlooked anything in my assessment. In no way did I mean to step on any toes. :-)

-l

The hyperthreading covert information leakage is unlikely to be a problem in Linux since Linux doesn't have true "threads". Each thread is represented by a process and the author states that multiple processes wouldn't be able to use the Processor L1 cache due to process switching overhead.

This exploit also uses a few "small" [sic] bits of handwaving:

1) Ability to syncronize the two separate processes. This was done for the author's example by using a debugger, "spy" to "know" when openssl was started and when it ended (p6).

2) quite another bit of handwaving with "On an otherwise quiescent system" (p6)

3) On a trusted OS, how did "trojans" and "spy" programs get loaded? On such systems, it is usually not the case that even compilers are availabe let alone the ability to load programs on demand.

On a trusted OS, a trojan might, at best, be loaded by a low-level browswer/download process. On a MLS, the user doing the downloading doesn't (or shouldn't) have administrative access to allow a trojan or a spy access to realtime functions like "process debugging", and "process scheduling" (perhaps including the "sched_yield" function.

It is quite likely that on a properly configured MLS system, web browsing would be done at a lowest level of priviledge, where only previously installed programs are allowed to run -- i.e. you can't download a trojan and have it be runnable. Anything downloadable to a writable partition has the "noexec" bit set. This is not user-changeable by a user with Mandatory Access Control's in place (often used with MLS to prevent privilege elevation).

4) It's unlikely that a MLS secure system with MAC (vs. Discretionary Access control, or DAC) would even be hooked up to the internet.

The whole bit describes an unlikely scenario in a MLS(usually MAC) system.

None of this means the author hasn't done his homework and there isn't a risk
of covert channels using this means, but in the real world, super secure systems shouldn't be running code that hasn't been rigorously examined and proven to some "Effective Assurance Level" (EAL).

The whole bit of caching could be extended to the Linux block cache, but in such a scenario, to provide true Level Separation, different priviledge levels likely wouldn't use the same block devices -- and hopefully, Processesors could have a bit as to whether to divide the cache/processor or to allow cache sharing (which would benefit performance for most apps).

Also, I might ask -- how would two different threads of the same process get two different levels of security clearance -- that just seems like dangerous programming and such a program would likely not be approved for most MLS systems.

It is a good paper, and it raises good issues to be aware of, but in practice it doesn't seem easily implemented.

However -- that stated -- there have always been known information leakage problems on multi-user computers. Simply measure latency in key echo's, network pings and program performance. All of these can be used to leak bits of information.

As for getting 310 bits out of 512...who's using 512 byte RSA keys these days? Bruce Schneier, in 1995 listed 1280-2048 bits for an RSA key.

Some symple preventive measures for now: 1) don't allow different threads in same process to have different security levels. 2) don't run untrusted programs on a "secure" system. 3) providing L2 cache separation _might_ be useful for some small number of government users trying to run an MLS on one machine, but it seems it'd be more assurance for them to use two separate processors in two separate machines physically separate machines running at different security levels.

Sorry if I've overlooked anything in my assessment. In no way did I mean to step on any toes. :-)

-l

My argument may not be obvious, but it's not hard to follow, either. It centers around the notion that security must be evaluated not based on how it works, but on how it fails.

It doesn't really matter how well an ID card works when used by the hundreds of millions of honest people that would carry it. What matters is how the system might fail when used by someone intent on subverting that system: how it fails naturally, how it can be made to fail, and how failures might be exploited.

I thought it was worth repeating.

Check out what Bruce Schneier has to say about the identity theft possibilities!

A lot of people don't seem to understand why people object to such a harmless concept as a national ID. Here's a good explanation from http://www.schneier.com/crypto-gram-0404.html#1

***

As a security technologist, I regularly encounter people who say the United States should adopt a national ID card. How could such a program not make us more secure, they ask?

The suggestion, when it's made by a thoughtful civic-minded person like Nicholas Kristof in the New York Times, often takes on a tone that is regretful and ambivalent: Yes, indeed, the card would be a minor invasion of our privacy, and undoubtedly it would add to the growing list of interruptions and delays we encounter every day; but we live in dangerous times, we live in a new world....

It all sounds so reasonable, but there's a lot to disagree with in such an attitude.

The potential privacy encroachments of an ID card system are far from minor. And the interruptions and delays caused by incessant ID checks could easily proliferate into a persistent traffic jam in office lobbies and airports and hospital waiting rooms and shopping malls.

But my primary objection isn't the totalitarian potential of national IDs, nor the likelihood that they'll create a whole immense new class of social and economic dislocations. Nor is it the opportunities they will create for colossal boondoggles by government contractors. My objection to the national ID card, at least for the purposes of this essay, is much simpler.

It won't work. It won't make us more secure.

In fact, everything I've learned about security over the last 20 years tells me that once it is put in place, a national ID card program will actually make us less secure.

My argument may not be obvious, but it's not hard to follow, either. It centers around the notion that security must be evaluated not based on how it works, but on how it fails.

It doesn't really matter how well an ID card works when used by the hundreds of millions of honest people that would carry it. What matters is how the system might fail when used by someone intent on subverting that system: how it fails naturally, how it can be made to fail, and how failures might be exploited.

The first problem is the card itself. No matter how unforgeable we make it, it will be forged. And even worse, people will get legitimate cards in fraudulent names.

Two of the 9/11 terrorists had valid Virginia driver's licenses in fake names. And even if we could guarantee that everyone who issued national ID cards couldn't be bribed, initial cardholder identity would be determined by other identity documents... all of which would be easier to forge.

Not that there would ever be such thing as a single ID card. Currently about 20 percent of all identity documents are lost per year. An entirely separate security system would have to be developed for people who lost their card, a system that itself is capable of abuse.

Additionally, any ID system involves people... people who regularly make mistakes. We all have stories of bartenders falling for obviously fake IDs, or sloppy ID checks at airports and government buildings. It's not simply a matter of training; checking IDs is a mind-numbingly boring task, one that is guaranteed to have failures. Biometrics such as thumbprints show some promise here, but bring with them their own set of exploitable failure modes.

But the main problem with any ID system is that it requires the existence of a database. In this case it would have to be an immense database of private and sensitive information on every American -- one widely and instantaneously accessible from airline check-in stations, police cars, schools, and so on.

The security risks are enormous. Such a database would be a kludge of existing databases; databases that are incompatible, full of erroneous data, and unreliable. As computer scientists, we do not know how to keep a database of

You think thats secure? For the ultra paranoid I've encrypted it into ROT26:

Could you introduce yourself ?

I'm a security technologist. My career has been a series of generalizations. I started working in cryptography: mathematical security. Then I realized that all the cryptography in the world won't help if the computer is insecure, and all the computer security won't help if the network is insecure. Since then, I have been concentrating more on the social and economic aspects of security, realizing that all the technology in the world won't help if those aren't done right.

More on my background can be found on schneier.com

NSA licensed Certicom's EC patents for $25 million last year, and recently announced the new US government standard for key agreement and digital signatures, called Suite B. It uses Elliptic Curve Diffie-Hellman (ECDH) and Elliptic Curve Menezes-Qu-Vanstone (ECMQV) for key agreement, and Elliptic Curve Digital Signature Algorithm (ECDSA) for signature generation/verification. Do you think that NSA is promoting ECC based crypto because they cannot crack RSA/DSA based one ?

I do not. I believe the NSA believes that ECC is strong. I wrote about ECC here:
http://www.schneier.com/crypto-gram-9911.html#Elli pticCurvePublic-KeyCryptography

Although I wrote that in 1999, I am still skeptical about elliptic curves.

Or maybe just because they can crack RSA/DSA they prefer to protect USbusiness with ECC (supposed to be harder to crack)?

With sufficient key lengths, all of this is uncrackable. I don't believe that the NSA has any secret mathematics that they use to break RSA/DSA or ECC.

Would a quantum computer do the job ?

In theory, yes. In practice, we have no idea how to build one to do it. Maybe in fifty years. Or twenty-five.

Some time ago you co-authored a paper on software monopoly risks. What about crypto monopoly? Don't you think that having just a couple of public-key algorithms based on the same math problem could lead to a catastrophe if cracked ?

The security advantages of a common cryptographic algorithm far outweigh the disadvantages. I've written about that as well:

http://www.schneier.com/crypto-gram-9904.html#diff erent.

What would you do if you found a solution to the factorization problem?

Any cryptographer, if they found something so significant as a solution of the factorization, would publish their results. Such a discovery would likely result in profound changes in how we view number theory, and would be the mathematical discovery of the decade...and maybe even more important.

Since most crypto protocols on the internet, such as SSL or SSH, uses public-keys to build a secure channel, wouldn't a unexpected public disclosure create a chaos on the internet ?

No. Chaos is hard to create, even on the Internet.

Here's an example. Go to Amazon.com. Buy a book without using SSL. Watch the total lack of chaos.

In the security community there are various ways of thinking about vulnerabilities disclosure (public-, full-, responsible-, no-). What is the situation in the crypto community ? What type of disclosure process is there ?

Most security professionals believe in full disclosure, and cryptographers are no exception. The advancement of the science is best served by the free exchange of ideas.

Why is often used a money-rewarded challenge to verify a crypto algorithm?

Because it's free consulting work, and money is an attempt to add some financial incentive. Most of the time it's a sham. While there are some legitimate contests, most are just attempts to gain publicity.

Recently some papers addressing hash functions were published, and you suggested on your blog that it's time to get to work r

You think thats secure? For the ultra paranoid I've encrypted it into ROT26:

Could you introduce yourself ?

I'm a security technologist. My career has been a series of generalizations. I started working in cryptography: mathematical security. Then I realized that all the cryptography in the world won't help if the computer is insecure, and all the computer security won't help if the network is insecure. Since then, I have been concentrating more on the social and economic aspects of security, realizing that all the technology in the world won't help if those aren't done right.

More on my background can be found on schneier.com

NSA licensed Certicom's EC patents for $25 million last year, and recently announced the new US government standard for key agreement and digital signatures, called Suite B. It uses Elliptic Curve Diffie-Hellman (ECDH) and Elliptic Curve Menezes-Qu-Vanstone (ECMQV) for key agreement, and Elliptic Curve Digital Signature Algorithm (ECDSA) for signature generation/verification. Do you think that NSA is promoting ECC based crypto because they cannot crack RSA/DSA based one ?

I do not. I believe the NSA believes that ECC is strong. I wrote about ECC here:
http://www.schneier.com/crypto-gram-9911.html#Elli pticCurvePublic-KeyCryptography

Although I wrote that in 1999, I am still skeptical about elliptic curves.

Or maybe just because they can crack RSA/DSA they prefer to protect USbusiness with ECC (supposed to be harder to crack)?

With sufficient key lengths, all of this is uncrackable. I don't believe that the NSA has any secret mathematics that they use to break RSA/DSA or ECC.

Would a quantum computer do the job ?

In theory, yes. In practice, we have no idea how to build one to do it. Maybe in fifty years. Or twenty-five.

Some time ago you co-authored a paper on software monopoly risks. What about crypto monopoly? Don't you think that having just a couple of public-key algorithms based on the same math problem could lead to a catastrophe if cracked ?

The security advantages of a common cryptographic algorithm far outweigh the disadvantages. I've written about that as well:

http://www.schneier.com/crypto-gram-9904.html#diff erent.

What would you do if you found a solution to the factorization problem?

Any cryptographer, if they found something so significant as a solution of the factorization, would publish their results. Such a discovery would likely result in profound changes in how we view number theory, and would be the mathematical discovery of the decade...and maybe even more important.

Since most crypto protocols on the internet, such as SSL or SSH, uses public-keys to build a secure channel, wouldn't a unexpected public disclosure create a chaos on the internet ?

No. Chaos is hard to create, even on the Internet.

Here's an example. Go to Amazon.com. Buy a book without using SSL. Watch the total lack of chaos.

In the security community there are various ways of thinking about vulnerabilities disclosure (public-, full-, responsible-, no-). What is the situation in the crypto community ? What type of disclosure process is there ?

Most security professionals believe in full disclosure, and cryptographers are no exception. The advancement of the science is best served by the free exchange of ideas.

Why is often used a money-rewarded challenge to verify a crypto algorithm?

Because it's free consulting work, and money is an attempt to add some financial incentive. Most of the time it's a sham. While there are some legitimate contests, most are just attempts to gain publicity.

Recently some papers addressing hash functions were published, and you suggested on your blog that it's time to get to work r

Could you introduce yourself ?

I'm a security technologist. My career has been a series of generalizations. I started working in cryptography: mathematical security. Then I realized that all the cryptography in the world won't help if the computer is insecure, and all the computer security won't help if the network is insecure. Since then, I have been concentrating more on the social and economic aspects of security, realizing that all the technology in the world won't help if those aren't done right.

More on my background can be found on schneier.com

NSA licensed Certicom's EC patents for $25 million last year, and recently announced the new US government standard for key agreement and digital signatures, called Suite B. It uses Elliptic Curve Diffie-Hellman
(ECDH) and Elliptic Curve Menezes-Qu-Vanstone (ECMQV) for key agreement,
and Elliptic Curve Digital Signature Algorithm (ECDSA) for signature generation/verification. Do you think that NSA is promoting ECC based crypto because they cannot crack RSA/DSA based one ?

I do not. I believe the NSA believes that ECC is strong. I wrote about ECC here:
http://www.schneier.com/crypto-gram-9911.html#Elli pticCurvePublic-KeyCryptography

Although I wrote that in 1999, I am still skeptical about elliptic curves.

Or maybe just because they can crack RSA/DSA they prefer to protect US business with ECC (supposed to be harder to crack)?

With sufficient key lengths, all of this is uncrackable. I don't believe that the NSA has any secret mathematics that they use to break RSA/DSA or ECC.

Would a quantum computer do the job ?

In theory, yes. In practice, we have no idea how to build one to do it. Maybe in fifty years. Or twenty-five.

Some time ago you co-authored a paper on software monopoly risks. What about crypto monopoly? Don't you think that having just a couple of public-key algorithms based on the same math problem could lead to a catastrophe if cracked ?

The security advantages of a common cryptographic algorithm far outweigh the disadvantages. I've written about that as well:

http://www.schneier.com/crypto-gram-9904.html#diff erent.

What would you do if you found a solution to the factorization problem?

Any cryptographer, if they found something so significant as a solution of the factorization, would publish their results. Such a discovery would likely result in profound changes in how we view number theory, and would be the mathematical discovery of the decade...and maybe even more important.

Since most crypto protocols on the internet, such as SSL or SSH, uses public-keys to build a secure channel, wouldn't a unexpected public disclosure create a chaos on the internet ?

No. Chaos is hard to create, even on the Internet.

Here's an example. Go to Amazon.com. Buy a book without using SSL. Watch the total lack of chaos.

In the security community there are various ways of thinking about vulnerabilities disclosure (public-, full-, responsible-, no-). What is the situation in the crypto community ? What type of disclosure process is there ?

Most security professionals believe in full disclosure, and cryptographers are no exception. The advancement of the science is best served by the free exchange of ideas.

Why is often used a money-rewarded challenge to verify a crypto algorithm?

Because it's free consulting work, and money is an attempt to add some financial incentive. Most of the time it's a sham. While there are some legitimate contests, most are just attempts to gain publicity.

Recently some papers addressing hash functions were published, and you suggested on your blog that it's time to get to work replacing SHA. You wrote: "The NIST already has standards for longer -- and harder to break -- ha

Could you introduce yourself ?

I'm a security technologist. My career has been a series of generalizations. I started working in cryptography: mathematical security. Then I realized that all the cryptography in the world won't help if the computer is insecure, and all the computer security won't help if the network is insecure. Since then, I have been concentrating more on the social and economic aspects of security, realizing that all the technology in the world won't help if those aren't done right.

More on my background can be found on schneier.com

NSA licensed Certicom's EC patents for $25 million last year, and recently announced the new US government standard for key agreement and digital signatures, called Suite B. It uses Elliptic Curve Diffie-Hellman
(ECDH) and Elliptic Curve Menezes-Qu-Vanstone (ECMQV) for key agreement,
and Elliptic Curve Digital Signature Algorithm (ECDSA) for signature generation/verification. Do you think that NSA is promoting ECC based crypto because they cannot crack RSA/DSA based one ?

I do not. I believe the NSA believes that ECC is strong. I wrote about ECC here:
http://www.schneier.com/crypto-gram-9911.html#Elli pticCurvePublic-KeyCryptography

Although I wrote that in 1999, I am still skeptical about elliptic curves.

Or maybe just because they can crack RSA/DSA they prefer to protect US business with ECC (supposed to be harder to crack)?

With sufficient key lengths, all of this is uncrackable. I don't believe that the NSA has any secret mathematics that they use to break RSA/DSA or ECC.

Would a quantum computer do the job ?

In theory, yes. In practice, we have no idea how to build one to do it. Maybe in fifty years. Or twenty-five.

Some time ago you co-authored a paper on software monopoly risks. What about crypto monopoly? Don't you think that having just a couple of public-key algorithms based on the same math problem could lead to a catastrophe if cracked ?

The security advantages of a common cryptographic algorithm far outweigh the disadvantages. I've written about that as well:

http://www.schneier.com/crypto-gram-9904.html#diff erent.

What would you do if you found a solution to the factorization problem?

Any cryptographer, if they found something so significant as a solution of the factorization, would publish their results. Such a discovery would likely result in profound changes in how we view number theory, and would be the mathematical discovery of the decade...and maybe even more important.

Since most crypto protocols on the internet, such as SSL or SSH, uses public-keys to build a secure channel, wouldn't a unexpected public disclosure create a chaos on the internet ?

No. Chaos is hard to create, even on the Internet.

Here's an example. Go to Amazon.com. Buy a book without using SSL. Watch the total lack of chaos.

In the security community there are various ways of thinking about vulnerabilities disclosure (public-, full-, responsible-, no-). What is the situation in the crypto community ? What type of disclosure process is there ?

Most security professionals believe in full disclosure, and cryptographers are no exception. The advancement of the science is best served by the free exchange of ideas.

Why is often used a money-rewarded challenge to verify a crypto algorithm?

Because it's free consulting work, and money is an attempt to add some financial incentive. Most of the time it's a sham. While there are some legitimate contests, most are just attempts to gain publicity.

Recently some papers addressing hash functions were published, and you suggested on your blog that it's time to get to work replacing SHA. You wrote: "The NIST already has standards for longer -- and harder to break -- ha

http://www.schneier.com/blog

Sorry about that!

It's http://www.schneier.com/

Like I said - "state issued". The real problem is that identification cards - whether mandated or burned into our foreheads at birth - don't do anything to significantly increase security. They DO however, provide a false sense of same, cause a lot of aggravation, and cost a lot of money.

I strongly recommend e.g. this link:

http://www.schneier.com/crypto-gram-0402.html#6

As Bruce says it better than I.