Slashdot Mirror

Broadband != high bandwidth.

Broadband signalling means multiple frequencies on the media, as opposed to baseband, where there is only one. Ethernet is a baseband technology.

These sorts of misconceptions result in well-defined technical terms such as broadband being re-defined for consumers as meaning something entirely different - because consumers have been led to believe it means something else. "Define broadband please - CA" It's one more way marketing continues to make life difficult for the technologists.

Please don't contribute to the problem. I stop taking people seriously pretty quickly when they use the CompUSA Salesdrone definition of a technical term, instead of the correct one.

As to your worm vector scenario, you aren't really describing anything different than what happens inside a large corporate LAN/WAN infrastructure. Use IDS software which can dynamically re-write your switch and router ACLs, educate your end-users as much as possible, and hire smart and driven sysadmins and techs who enjoy the challenge of keeping up with the black hats. Provide them with good equipment and quality caffeine.

And never sit back and relax, confident that you're secure.

Security is a process, not a product. It's an endless, arduous, thankless process. - Bruce Schneier

scubaduba, interesting interview. I see some of the same themes that he's talked about in the past. He is quite concerned about the effects of technology on the average person which he discusses in some detail in the interview linked below.

Here's an interview with Eugene Spafford in two parts that outlines a lot of the issues that he's concerned with. It provides some background and insights into his thinking. I found his views on the purpose of security technology especially interesting and somewhat unexpected. The same goes for his indirect criticism of Microsoft, which speaks to his comment in the Greplaw interview about 'using the right tools for the right jobs.'

Description courtesy of Bruce Schneier's Crypto-gram:

Long and interesting interview with Gene Spafford, about the infosec threat landscape; privacy; the challenges of digital certificates, CRLs, public key infrastructure standards and interoperability; key escrow, backup and recovery; identity fraud; trust on the Internet; and the problems of security education today. Sample quote: "Security doesn't work as an add-on. It really needs to be built-in from the beginning."

Bruce Schneier put forward the hypothesis that the problems at FirstEnergy were caused by the MSBlast virus. The company is generally considered the place where the problem could have been prevented, but their operational computers failed to sound the alarm at the critical moment. In fact, "for over an hour no one in FE's control room grasped that their computer systems were not operating properly, even though FE's Information Technology support staff knew of the problems and were working to solve them." What "problems" were these? Well, we don't know, but this happened at exactly the time that MSBlast was spreading...and isn't that just...interesting.

It's only a hypothesis, of course. His argument is basically, "Here's some really, really compelling circumstantial evidence; somebody should look in to this."

I wonder: Did anybody look into it? Has anybody heard any more about this intriguing theory? Do we know what the problem with the operational machines actually was from this new report? Just what problem was FirstEnergy's IT staff fixing?

Well, I for one, probably won't go to Java One this year because of this. That's about $10 k out of the San Francisco area economy. Now apply that to all the foriegn visitors for all the conference places like the Moscone Centre host in a year.

All it does is get my identity into a database for a foreign country to use against me. And since I'm not a citizen, I have no right to see how the information is being used or whether it's accurate.

I personally think Canada's security is OK. We'll arrest you when we have the evidence, as we recently did in Ottawa (where I live), not before.

BTW, if you think taking pictures and finger prints is going to increase security, you are living in a dream world. Try reading any of the last 5 or 10 Cryptograms and let Bruce Schneier tell you why it will likely make us less secure.

It an unescesary invasion of my privacy. Having my fingerprints will not help the US deter or track terrorists.

[..] completely nonpublic disclosure of many application-specific vulnerabilities would fix these problems and filter out most actual acts of exploiting security holes.

Nice idea in theory. However, history has shown us that without the threat of full disclosure hanging over their heads, vendors will not fix vulnerabilities in time.

Also, full disclosure, while giving hackers the tools to exploit a hole, will also at the same time give sysadmins and users the information to close or work around the security vulnerability.

So while the chances of an initial exploit may rise, the 'Window of Exposure' is dramatically shrunk. Bruce Schneier has written a good essay on both the history and the theory behind Full Disclosure. Read it.

With no doubt, this must be the biggest security hole I have seen lately. 802.11g directly to the hard drive. Bravo. Is this an April Fool's joke posted prematurely or are they really out of their minds thinking that anyone would be so stupid to buy such a hard drive, which is basically asking to be cracked? I find it insulting. I hope script kiddies will have lots of fun.

With no doubt, this must be the biggest security hole I have seen lately. 802.11g directly to the hard drive. Bravo. Is this an April Fool's joke posted prematurely or are they really out of their minds thinking that anyone would be so stupid to buy such a hard drive, which is basically asking to be cracked? I find it insulting. I hope script kiddies will have lots of fun.

At first, the concept of a global authentication system seems great.

No, I'm sorry but it does not for anyone who is serious about security.

We all have too many passwords to remember, the idea behind Passport seems great.

There is much better solution for that problem, Password Safe:

"Many computer users today have to keep track of dozens of passwords: for network accounts, online services, premium web sites. Some write their passwords on a piece of paper, leaving their accounts vulnerable to thieves or in-house snoops. Others choose the same password for different applications, which makes life easy for intruders of all kinds."

"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."

But in reality, there isn't anyone who is secure enough, trustworthy enough, powerful enough and smart enough to pull off a system that would work and would be trusted.

Of course there isn't anyone who might be able to implement such a system, becuase the whole idea is inherently flawed.

I use Password Safe to store my passwords. The program can fit on a floppy disk, and doesn't modify the registry. It is a free, open source program, and the database file is in your control. (I keep a copy on yahoo briefcase, so I can access it anywhere)

It does have the single point of failure issue, but I consider this an acceptable trade off considering I now use very long, complex and different passwords for everything.

I had no idea how many UID's/Passwords I had until I started using this program.

[Suppose t]here are 10 $100 piles, each secured by individual $200 security systems. They're all secure. There are another 10 $100 piles, each secured by individual $50 systems. They're all insecure.

Clearly something must be done.

One suggestion is to replace all the individual security systems by a single centralized system. The new system is much better than the ones being replaced; it's a $500 system.

Unfortunately, the new system won't provide more security. Under the old systems, 10 piles of money could be stolen at a cost of $50 per pile; an attacker would realize a total profit of $500. Under the new system, we have 20 $100 piles all secured by a single $500 system. An attacker now has an incentive to break that more-secure system, since he can steal $2000 by spending $500 -- a profit of $1500.

The problem is centralization. When individual security systems are combined in one centralized system, the incentive to break that new system is generally higher. Even though the centralized system may be harder to break than any of the individual systems, if it is easier to break than ALL of the individual systems, it may result in less security overall.

There is a security benefit to decentralized security.

IPsec is often sold as one of the wonderful things coming with IPv6 (but also available with IPv4), but its complexity is likely to make the recent OpenSSL vulns appear as a little joke...

Yeah, an' denial is a river in Egypt ...

I have read that paper (when it was first published in response to the original CAPPS) and consider their reasoning to be correct.

For more info on dubious "Passenger Prescreening" proposals see Bruce Schneier on "i'm not at Terrorist" cards

Call Your Reps For Free

A toll free number has been set up for the US Senate and Congress at +1-800-839-5276. They immediately answer "Capitol" and will happily transfer you to your congressional representatives. Call during business hours and feel free to speak your mind, asking them not to expand the Patriot act, repeal the DMCA, push through donotcall.gov, etc.

The creators of this idea should have read this opinion piece before proceeding with their DDos counterattack initiative.

Bruce Schneier has a very interesting article about the "Scam" that is the Public Key Infrastructure.

Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure

This is probably just the first of many security problems resulting from the fact that these PKI issuing authorities are more interested in Money and Marketing, than in actual security...

Why was this modded up? Just mindless MS bashing with no facts to back it up.

• SOAP and it's security bypassing
• More about SOAP's deliberate attempt to subvert network security

Now, granted, I did make a connection that SOAP was the only protocol for inter-device communication in .Net (it isn't). But considering Microsoft has been encouraging developers to think about making every .NET service SOAP enabled, it's hard not to wonder...

.Net, conceptually, sounds neat but Microsoft still has a single, non-networked PC mentality. I didn't even mention Linux/Apache/PHP/Java/etc becuase it's not about them being better or worse. It's about the fact that .Net was an idea pushed out as a "neat idea" without thinking through its implications.

I'd read the first things Microsoft officially published about it back when they were hot of the keyboards of the developers. .NET is a neat idea, but the security implications are scary. .NET applications are expected to exchange code and run remotely. They have a grand vision of .NET code being swapped across the planet and running on everything from your cellphone to mission critical servers. Creating a monoculture where a malicious worm can spread like wildfire before anyone can even react is a frightning thought.

Saying "Well, it's up to the developer to make it secure" is like saying "Well, it's up to the sysadmin to apply the Blaster patches". They should, but they won't.

The Chamelon Card system uses a fingerprint reader to secure the data vault. Fingerprint readers can be defeated using a simple hack involving common household items. I refer interested readers to the following article: http://www.schneier.com/crypto-gram-0205.html.

Everyone interested in this issue should take a look at the VerifiedVoting Website.

Electronic voting needs to solve two problems: Guarantee that every vote is counted exactly and guarantee that everyone can trust that result.

As Schneier points out, there can be no trust without a paper trail for verification. So it is quite important to support legislation mandating such a paper trail.

Amazing. Considering who's heading things up, I guess one should *not* be suprised to see that Counterpane and Bruce Schneier are not part of the list.

Mr. Schneier represents a calm voice that is firmly, lucidly, and actively opposed to the tradeoffs being made by giving away too much liberty in return for too little new security.

He's got some excellent essays here. Highly recommended.

Cadmann

isn't it much more likely that having their own key in there allows them to sign their own Crypto components for internal use without having to have Microsoft see their secret alterations, or without having Microsofts private key?

http://www.schneier.com/crypto-gram-9909.html#NSAK eyinMicrosoftCryptoAPI
i mean, really... I can understand Tin Foil Hat theories, but sometimes I think that the hat must be too constricting, affecting mental processes...

Bruce Schneier gives a pretty good argument that this will not end spam.

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

For any biometric, once there is a way to trick it, you are screwed. You can't change your fingerprint like you can get a new password, and the massive infrastructure investment in the biometric system pretty much guarantees the bureaucracy will just try to pretend it isn't happening.

The weakest link in any cryptography protocol is the key, reguardless of how big it is.

That's totally incorrect. In fact, the weakest link is almost never the key size. The failure point in protocols often has nothing to do with the security of the underlying cryptographic primative. PGP's file format lead to a break in the PGP system without attacking any of the cryptographic primatives. Similarly, SSL was broken on netscape because of a faulty choice of random number generator. Wep was broken in 802.11b devices due a series of flaws that didn't break the underlying algorithms. Cipher design is very difficult but it's only the easy part. Protocols are a nightmare.

During the cold war some soviet spy's would use an encryption scheme where a single bit of the key would decrypt a single bit of the message, after decryption the bits of the key that were used to decrypt were thrown away. The key had to be huge and it could only be used for a certain number of messages. That type of encryption is called a one time pad, it's nearly impossible to break. The common encryption schemes today like RSA or DES go for reusable keys but you still need to switch your key's every so often.

It is unbreakable but people often sing it's praises and neglect the fact you have to get this key to the other party you want to communicate with. Since the One time pad (OTP) is the *same* size as the plain-text you want to communicate then surely it's just as easy to communicate the actual message? In some cases it's useful, like where you can give someone they pad before they start their covert mission but in a modern internet setting the OTP is useless.

Generally the idea is to make the key as large as possible. There will always be a cap in how large one can go. Limitations in computing power can make the time needed to decrypt a message with a large key unacceptable. Maybe the key needs to fit onto some ealy concealable physical medium, or maybe it needs to be remembered. The idea is to acertain your upper limit and use keys that are that length

Again, another misconception. Bigger keys do not have a huge impact on performance if your using a block cipher. I could make DES use 768-bit keys if I dumped the key schedule and used independant subkeys. It wouldn't improve it's security either. Infact, differential cryptanalysis of DES and it's varient is generally done by assuming the subkeys are independant. Bigger keys do not always equal bigger security.

I stand by my original analysis. Smaller keys are better because they're easier to protect. The only need to be big enough to resist brute-force and there is no use in increasing the size further.

Enigma encryption might have been a great leap ahead and looked completely state of art in the WW2, but today, it's quite trivial to crack. Enigma could be easily bruteforced - just check through the entire keyspace.

It also probably wouldn't stand too long if real crypto breakers who knew their stuff would start their job without knowing anything about the encryption scheme, even. The science has gone so far in recent times.

And an easy way to illustrate: Compare output from Enigma with any modern cipher. Enigma output looks like completely mangled words - the text is garbled, the layout of the message is exposed. Modern cipher output looks like a completely random arrangement of bits, everything completely spread around the message with no point to really take a good grip on. With Enigma, if you know that Nazi guy is always putting "Heil Hitler" at the end, you have already cracked that much of the message.

If the thing looks trivial, then it probably is. If it doesn't, it probably isn't. Of course, this isn't always true in either way.

Now I'll get more coffee so I can start making sense today.

I'd use Wireless USB in preference to Bluetooth if they can get the crypto and security right. The key exchange is messed up, the encryption they used has real problems, and they elected not to include the most important component - strong authentication - meaning that it's possible (for example) for someone to inject false keystrokes if you use a Bluetooth keyboard. (about Bluetooth security Schneier talks about the keyboard injection attack)

What I want to hear is that David Wagner, Ross Anderson and Don Coppersmith have been called in to design the security for this new protocol. Then we might see something half decent.

Let's be fair. I don't know that Blaster caused the blackout. The report doesn't say that Blaster caused the blackout. Conventional wisdom is that Blaster did not cause the blackout. But it seems more and more likely that Blaster was one of the many causes of the blackout. Regardless of the answer, there's a very important moral here. As networked computers infiltrate more and more of our critical infrastructure, that infrastructure is vulnerable not only to attacks but also to sloppy software and sloppy operations. And these vulnerabilities are invariably not the obvious ones. The computers that directly control the power grid are well-protected. It's the peripheral systems that are less protected and more likely to be vulnerable. And a direct attack is unlikely to cause our infrastructure to fail, because the connections are too complex and too obscure. It's only by accident--Blaster affecting systems at just the wrong time, allowing a minor failure to become a major one--that these massive failures occur.

As a employee of a large content provider, what current options are out there for groups that want to deploy protected content on Linux?

Well, you could start by reading a book. DRM is not viable on closed source systems; it won't be viable on open source systems. If you plug DRM software into the kernel, I can still run it inside a virtual machine and snatch out whatever content I want (and put it on a peer-to-peer system). Better yet, I can get content from someone who doesn't try to treat me like a two-year-old.

Want a real system for getting money for your content? Try micropayments, or subscription, but don't bother with DRM. Any engineer (who isn't trying to part a fool from his venture capital) will tell you that, in the long run, "trying to make bits uncopyable is like trying to make water not wet." (Thanks, Bruce)

There are problems with Bluetooth by design. For one thing, no wireless protocol for interaction between devices can be truly secure unless peering requires physical contact between them (I place my phone next to my laptop, but the spook across the street has a directed antenna that is a thousand times stronger then the phone...)

It isn't like this hasn't come up before, Schneier predicted that Bluetooth would be a security nightmare three and a half years ago ! Quoting:

What amazes me is the dearth of information about the security of this protocol. I'm sure someone has thought about it, a team designed some security into Bluetooth, and that those designers believe it to be secure. But has anyone reputable examined the protocol? Is the implementation known to be correct? Are there any programming errors? If Bluetooth is secure, it will be the first time ever that a major protocol has been released without any security flaws. I'm not optimistic.

And what about privacy? Bluetooth devices regularly broadcast a unique ID. Can that be used to track someone's movements?

The stampede towards Bluetooth continues unawares. Expect all sorts of vulnerabilities, patches, workarounds, spin control, and the like. And treat Bluetooth as a broadcast protocol, because that's what it is.

No, this is not a smart policy, unless you mean for PR. (worked to get a posting on /.)

Cracking contests have been debunked many times. If no one comes forward and admits to successfully cracking the target, it does not mean that no one cracked it (why blab about it instead of letting the exploitable product go to market with a nice big hole that you already know how to exploit?) If anyone does come forward, that does not mean that all holes were found, only the hole someone was willing to admit to finding.

Bruce Schneier has written quite a bit about the fallacy of cracking contests in Cryptogram (eg. November 2000 and December 1998, which links back to a /. article with posts about the fallacy of cracking contests) and in Secrets and Lies.

The value of the cracking contest (or "hacker challenge") is in the publicity - bragging rights to say, "We co-opted the people most capable of exploiting us and they all failed." As another poster said, this adds nothing to the value an audit.

No, this is not a smart policy, unless you mean for PR. (worked to get a posting on /.)

Cracking contests have been debunked many times. If no one comes forward and admits to successfully cracking the target, it does not mean that no one cracked it (why blab about it instead of letting the exploitable product go to market with a nice big hole that you already know how to exploit?) If anyone does come forward, that does not mean that all holes were found, only the hole someone was willing to admit to finding.

Bruce Schneier has written quite a bit about the fallacy of cracking contests in Cryptogram (eg. November 2000 and December 1998, which links back to a /. article with posts about the fallacy of cracking contests) and in Secrets and Lies.

The value of the cracking contest (or "hacker challenge") is in the publicity - bragging rights to say, "We co-opted the people most capable of exploiting us and they all failed." As another poster said, this adds nothing to the value an audit.

No, this is not a smart policy, unless you mean for PR. (worked to get a posting on /.)

Cracking contests have been debunked many times. If no one comes forward and admits to successfully cracking the target, it does not mean that no one cracked it (why blab about it instead of letting the exploitable product go to market with a nice big hole that you already know how to exploit?) If anyone does come forward, that does not mean that all holes were found, only the hole someone was willing to admit to finding.

Bruce Schneier has written quite a bit about the fallacy of cracking contests in Cryptogram (eg. November 2000 and December 1998, which links back to a /. article with posts about the fallacy of cracking contests) and in Secrets and Lies.

The value of the cracking contest (or "hacker challenge") is in the publicity - bragging rights to say, "We co-opted the people most capable of exploiting us and they all failed." As another poster said, this adds nothing to the value an audit.

Seems vulnerable to traffic analysis, as someone mentioned you don't use a combination lock that sends packets all over the world. People will want more complicated sequences, but it will take more time to send them and they may have to resend due to TCP packets coming in different order. But even so anybody on your network or the server's network should be able to see what's going on, how secure is that? And if the server ever responds to your ip from any port then you likewise hosed.

On the other hand this does seem to be an interesting way to one-way send information to the server. I was thinking of playing solitaire using Bruce Schneier's algorithm using a port for each card of a deck.

IANA cypherpunk, but there seem to be a number of ways to treat the set of all closed ports as a numerical space that would be interesting for encrypted communications.

For example you could convert a one-time pad, a private key, or a set of communication channels into a list of port numbers. For a short message at least, you could send with pretty good security (although the list of ports, if not their hash values, would be known to the outside world).

To me this knocking stuff sounds like it only *reduces* security and provides lots of interesting clues to men in the middle. The intriguing part seems to be that you can send a good deal of information through a large number of half-connections in parallel, but this may have already been tried by other people. Of course if the message is simple enough that a single ping to a single prearranged port number is enough to convey it, then you would seem to have a pretty strong system though its existence would certainly be uncovered sooner or later. But if this became popular I suppose the advantage would be in being able to assign certain ports to prearranged values, both for encryption purposes and also to reduce the amount of data you actually need to send.

This is similar to credit card scam that Bruce Schneier pointed out in his latest cryptogram. Fooling people into eating poison wrapped up as a remedy. Bastards.

New Credit Card Scam

This one is clever.

You receive a telephone call from someone purporting to be from your credit card company. They claim to be from something like the security and fraud department, and question you about a fake purchase for some amount close to $500.

When you say that the purchase wasn't yours, they tell you that they're tracking the fraudsters and that you will receive a credit. They tell you that the fraudsters are making fake purchases on cards for amounts just under $500, and that they're on the case.

They know your account number. They know your name and address. They continue to spin the story, and eventually get you to reveal the three extra numbers on the back of your card.

That's all they need. They then start charging your card for amounts just under $500. When you get your bill, you're unlikely to call the credit card company because you already know that they're on the case and that you'll receive a credit.

It's a really clever social engineering attack. They have to hit a lot of cards fast and then disappear, because otherwise they can be tracked, but I bet they've made a lot of money so far.

How long before a keygen is out?
Depends if they used Yarrow or not.

At a minimum, electronic voting machines need to print out a paper receipt. That would allow a recount and increase accountability in the system. Without a paper receipt, you may not even be able to determine that an attack has occurred.

Bruce Schneier, author of Beyond Fear and the fantastic Applied Cryptography, has an old but good commentary on the some security issues of electronic voting machines in his Crypto-gram newsletter.

At a minimum, electronic voting machines need to print out a paper receipt. That would allow a recount and increase accountability in the system. Without a paper receipt, you may not even be able to determine that an attack has occurred.

Bruce Schneier, author of Beyond Fear and the fantastic Applied Cryptography, has an old but good commentary on the some security issues of electronic voting machines in his Crypto-gram newsletter.

Use OpenVPN instead - a breeze to install, secure, interoperable, etc.

... Here's an interview with Gene Spafford in two parts that outlines a lot of the issues that he's concerned with. It provides some background and insights into some of the thinking behind the guide. I found his views on the purpose of security technology especially interesting and somewhat unexpected. The same goes for his indirect criticism of Microsoft.

Description courtesy of Bruce Schneier's Crypto-gram:

Long and interesting interview with Gene Spafford, about the infosec threat landscape; privacy; the challenges of digital certificates, CRLs, public key infrastructure standards and interoperability; key escrow, backup and recovery; identity fraud; trust on the Internet; and the problems of security education today. Sample quote: "Security doesn't work as an add-on. It really needs to be built-in from the beginning."

# 2003-12-18 18:52:34 Cybercrime hits capitol hill (articles,usa) (rejected)

This was reported in the December issue of Cryptogram. You can find a Washington Post article here. And the Information Week article here.

I wouldn't waste a CPU cycle on this contest.

Bruce Schneier nailed the truth about cracking contests in a December 1998 article in his crypto-gram newsletter, "The Fallacy of Cracking Contests".

Here is another article he published in November 1999, "Elliptic Curve Public-Key Cryptography".

Interesting reading.

I wouldn't waste a CPU cycle on this contest.

Bruce Schneier nailed the truth about cracking contests in a December 1998 article in his crypto-gram newsletter, "The Fallacy of Cracking Contests".

Here is another article he published in November 1999, "Elliptic Curve Public-Key Cryptography".

Interesting reading.

By the way this is Schneier's recommendation on ECC:

My recommendation is that if you're working in a constrained environment where longer keys just won't fit -- smart cards, some cellphones or pagers, etc. -- consider elliptic curves. If the choice is elliptic curves or no public-key algorithm at all, use elliptic curves. If you don't have performance constraints, use RSA. If you are concerned about security over the decades (almost no systems are), use RSA.

If any of you is seriously considering going at this, I recommend the well known Applied Cryptography

Slashdot has reviewed this before.

From the guru Bruce Schneier, Fallacy of cracking contests

The main issue is that to protect its own workings, it would need to be closed source. There will be a slight problem with some system admins installing it in that event.

Why closed source?

Closed-source cryptographic systems (which is essentially what this is) are often very insecure if they are not peer-reviewed. In fact, Bruce Schneier argues often in his books that a properly designed cryptographic system is just as secure if the source/spec is open/published. Most problems are actually due to implementation weaknesses which argues for the "many eyes, bugs shallow" of open source code.

Go subscribe to Crypto-Gram or read up the back issues if you want to get a good background on what makes for secure systems.

Seriously, I'm the author of Speex (the speech codec) and I'd be willing to help if someone wanted to design an open-source library to encrypt VoIP packets.

Linking against twofish is trivial -- Niels Ferguson publishes a easy to use free twofish library in portable C. Twofish is unpatented, and the source code is uncopyrighted and license-free; it is free for all uses.

Another more generic option would be to link against the mcrypt GPL library.

This is a project I can't do only by myself because I lack the knowledge to use crypto stuff currectly (random stuff, padding, etc).

I think it would be nice to have such a library so that any VoIP application writer can easily integrate the crypto functionality.

I can't easily locate documentation on key exchange for the voice channel for VoIP call setup? All I see are a handful of papers on encryption on the SIP protocol.

This vaguely reminds me of the fraudulent Verisign / Microsoft code-signing digital certificates that Verisign issued a few years back.

While not an identical problem, an essential element of why those certificates were potentially harmful was also because of a problem with the CRL checking. Verisign didn't support CRL distribution points in their certificates and you all remember the problems that ensued.

I found security researcher Gene Spafford's comments on the PKI / Verisign issue interesting, which were picked up in Bruce Schneier's Crypto-Gram. Schneier's comments on the incident as well as the Microsoft response are also worth reading.

It's unbelievable that Verisign which claims to be in the business of Internet security and SSL/TLS digital certificates - the dominant company with 95%+ market share - could let their Root Certificate Authority expire, then force its users to effectively patch their systems by importing the new certificate for the root CA after the fact. That's just bad engineering.

Yes, end-users need to take some responsibility for their systems, but PKI and related technologies are complex and not for novices. It's no better than the keep-your patches-updated-and-use-a-firewall comment that Bill Gates made a couple of months ago. That's a bandage, not a solution.

This vaguely reminds me of the fraudulent Verisign / Microsoft code-signing digital certificates that Verisign issued a few years back.

While not an identical problem, an essential element of why those certificates were potentially harmful was also because of a problem with the CRL checking. Verisign didn't support CRL distribution points in their certificates and you all remember the problems that ensued.

I found security researcher Gene Spafford's comments on the PKI / Verisign issue interesting, which were picked up in Bruce Schneier's Crypto-Gram. Schneier's comments on the incident as well as the Microsoft response are also worth reading.

It's unbelievable that Verisign which claims to be in the business of Internet security and SSL/TLS digital certificates - the dominant company with 95%+ market share - could let their Root Certificate Authority expire, then force its users to effectively patch their systems by importing the new certificate for the root CA after the fact. That's just bad engineering.

Yes, end-users need to take some responsibility for their systems, but PKI and related technologies are complex and not for novices. It's no better than the keep-your patches-updated-and-use-a-firewall comment that Bill Gates made a couple of months ago. That's a bandage, not a solution.

Sounds like an interesting book. If you're interested in security topics, I can't recommend Bruce Schneider's (author of Applied Cryptography, among other things) Crypto-gram newsletter. It's free and gives a great overview of the news on computer security. His focus is often on ineffective security measures that people manage to avoid and how they can be improved. Well worth reading.

remember this slashdot article that reffered to that
crypto-gram issue ???

quote :
Fun with Fingerprint Readers

Tsutomu Matsumoto, a Japanese cryptographer, recently decided to look at biometric fingerprint devices. These are security systems that attempt to identify people based on their fingerprint. For years the companies selling these devices have claimed that they are very secure, and that it is almost impossible to fool them into accepting a fake finger as genuine. Matsumoto, along with his students at the Yokohama National University, showed that they can be reliably fooled with a little ingenuity and $10 worth of household supplies.

Matsumoto uses gelatin, the stuff that Gummi Bears are made out of. First he takes a live finger and makes a plastic mold. (He uses a free-molding plastic used to make plastic molds, and is sold at hobby shops.) Then he pours liquid gelatin into the mold and lets it harden. (The gelatin comes in solid sheets, and is used to make jellied meats, soups, and candies, and is sold in grocery stores.) This gelatin fake finger fools fingerprint detectors about 80% of the time.

His more interesting experiment involves latent fingerprints. He takes a fingerprint left on a piece of glass, enhances it with a cyanoacrylate adhesive, and then photographs it with a digital camera. Using PhotoShop, he improves the contrast and prints the fingerprint onto a transparency sheet. Then, he takes a photo-sensitive printed-circuit board (PCB) and uses the fingerprint transparency to etch the fingerprint into the copper, making it three-dimensional. (You can find photo-sensitive PCBs, along with instructions for use, in most electronics hobby shops.) Finally, he makes a gelatin finger using the print on the PCB. This also fools fingerprint detectors about 80% of the time.

Gummy fingers can even fool sensors being watched by guards. Simply form the clear gelatin finger over your own. This lets you hide it as you press your own finger onto the sensor. After it lets you in, eat the evidence.

Matsumoto tried these attacks against eleven commercially available fingerprint biometric systems, and was able to reliably fool all of them. The results are enough to scrap the systems completely, and to send the various fingerprint biometric companies packing. Impressive is an understatement.

There's both a specific and a general moral to take away from this result. Matsumoto is not a professional fake-finger scientist; he's a mathematician. He didn't use expensive equipment or a specialized laboratory. He used $10 of ingredients you could buy, and whipped up his gummy fingers in the equivalent of a home kitchen. And he defeated eleven different commercial fingerprint readers, with both optical and capacitive sensors, and some with "live finger detection" features. (Moistening the gummy finger helps defeat sensors that measure moisture or electrical resistance; it takes some practice to get it right.) If he could do this, then any semi-professional can almost certainly do much much more.

More generally, be very careful before believing claims from security companies. All the fingerprint companies have claimed for years that this kind of thing is impossible. When they read Matsumoto's results, they're going to claim that they don't really work, or that they don't apply to them, or that they've fixed the problem. Think twice before believing them.

Matsumoto's paper is not on the Web. You can get a copy by asking:
Tsutomu Matsumoto

Here's the reference:
T. Matsumoto, H. Matsumoto, K. Yamada, S. Hoshino, "Impact of Artificial Gummy Fingers on Fingerprint Systems," Proceedings of SPIE Vol. #4677, Optical Security and Counterfeit Deterrence Techniques IV, 2002.

Some slides from the presentation are here:
presentati