Posted by Scott Laird
Fri, 05 Aug 2005 13:27:21 GMT
Bruce Schneier says that the President has declared a national emergency and used it to extend the US export controls on cryptography. Apparently this happens every few years; Bush and Clinton have both done it.
As the article says, crypto exports really are a lot easier then they were in the ’90s, but there are still issues. We’ve had to deal with some of them at work, and it felt like a total throwback to days past–we need to file paperwork with the government before we can ship crypto software to Europe? Even though we’re just using the standard set of open-source crypto tools that we probably downloaded from Europe in the first place?
At least we didn’t actually need approval–just notification. It’s a step in the right direction, and no one’s actually afraid that the US will completely ban encryption tools anymore. That was a real fear for a while in the ’90s.
Posted in Computer Software | Tags crypto, cryptography, export, stateofemergency, us | no comments
Posted by Scott Laird
Wed, 13 Jul 2005 02:11:30 GMT
I’ve spent most of the past two days working on a little project at work that needs the ability to generate Java JKS keystore files (compatible with the Java keytool program) containing X.509 certificates signed by a private certificate authority.
If you think that sounds simple, then you’ve obviously never worked with X.509.
This turns out to be astoundingly difficult, largely because X.509 is insane. It doesn’t help that Sun’s keytool program is missing a lot of functionality–if you want to rename keys or extract the private keys from the keystore file, then you’ll need to resort to coding it in Java. It’s also really hard to find usable certificate authority software. I’ve been looking for it at least 8 years for a complete open-source corporate CA! There are lots of partial solutions out there, but none of the ones that I’ve used have actually been able to solve all of the problems that I’ve needed solved. I’ve always fallen back on scripting openssl directly, and that always requires a day or so of digging through OpenSSL documentation to find the right incantations to get it to work.
In the end, all I needed to do was run openssl 3 times per key generated (make key, sign key, convert to PKCS#12), then run a bit of Java code out of Jetty to convert the PKCS#12 key to a format that keytool can read. Don’t ask why I had to drag Jetty into the picture–that’s like requiring Apache in order to get your version control software to compile or something–it just doesn’t make any sense. Sigh.
For future reference, here are a few useful references:
Posted in Computer Security, Computer System Administration, Work | Tags cryptography, openssl, rant, x509 | 4 comments
Posted by Scott Laird
Tue, 17 May 2005 20:13:57 GMT
Bruce Schneier posted a link to an AES timing attack from Dan Bernstein.
This is similar to last week’s hyperthreading vulnerability, in that it exploits cache timing variances to extract sensitive information, but DJB’s attack is demonstrated working over a network–it doesn’t require that the attack code run on the same physical CPU as the encryption code. Instead, it exploits the fact that AES implementations need to do data-dependent lookups from tables, and the tables don’t fit entirely into the CPU’s fastest cache. Therefore, by closely watching the time it takes for a server to encrypt a packet and return a result, you can learn something about the key itself. By feeding the server millions of carefully-crafted packets and examining the timing results produced, he was able to narrow the keyspace substantially.
In this case, he was able to recover all 128 bits of a randomly-generated AES key in around a day. Most likely, the process could be optimized substantially by testing high-probablility keys against a known plaintext in parallel with the AES. I wouldn’t be surprised if an hour’s worth of traffic was enough to narrow the keyspace enough to make a brute-force attack possible. His notes also suggest a number of other optimizations that may lower the amount of work even further.
In general, any data-dependent timings anywhere in a crypto system will subject the system to this sort of problem. Unfortunately, it’s nearly impossible to eliminate all of the data-dependent timing issues on any modern computer–between cache issues, hidden optimizations in certain instructions, measurable delays when switching between cache banks, and an utter lack of comprehensive performance documentation, there’s really no easy way to avoid this class of problems on modern CPUs. The best you can do is minimize the amount of variance and force the attacker to use larger and larger amounts of traffic.
All in all, this probably isn’t just a theoretical attack. It isn’t something that random hackers will use, but it’s fast enough to be usable by a determined attacker with relatively low-latency network access to the victim’s system.
Posted in Computer Security | Tags aes, cryptography, djb, security, timingattack | no comments
Posted by Scott Laird
Fri, 13 May 2005 00:27:44 GMT
KernelTrap is reporting that a SFU grad student has found some sort of hyperthreading vulnerability. Details are slim, but he’s claiming some sort of information leakage between threads on a HT CPU, saying that this could lead to the disclosure of things like RSA private keys.
If I had to guess, I’d say that this is some sort of timing attack. Most likely, the leak occurs when one HT thread runs a predictable chunk of code with secret data while the other HT thread runs some sort of monitoring code, watching for things like cache misses or utilization of the various shared resources. Or maybe, Intel shares the CPU performance counters between the two threads so the attacking thread can simply extract detailed timing information from the other thread’s work, and then use the timing information to reconstruct details on what the attacked thread was doing. There’s a decent body of work on attacking smart cards using similar techniques.
Update: After doing a bit of research, it looks like Intel does share performance counter data between threads, and some of the data shared is really interesting, like branch prediction data–if you’re attacking a known body of code, you may actually be able to extract enough data from this to get a decent peak at the private key.
Update 2: The paper is online. If I’m reading this correctly, the basic attack uses timing measurements against the L1 and L2 caches to see when the RSA thread moves on to a new cache line worth of data. The attack doesn’t need access to anything more advanced then the CPU’s cycle-counter clock to be able to recover roughly 310 bits from a 512 bit key.
Personally, I find this to be fascinating from an academic standpoint but not terrifically useful in the real world. I don’t generally want untrusted users to have any access to systems with valuable keys. Historically, it hasn’t taken most attackers very long to turn untrusted shell access into a root exploit. In almost any case, a root exploit is more worrying then the loss of 310 bits from a 512 bit key–if the attacker had root, odds are they could recover the entire key directly.
This is clearly a problem that needs to be fixed by Intel, but I’m not planning on running around disabling Hypertheading on all of my systems today. It’s just not that dangerous of an exploit for most users.
Posted in Computer Security | Tags cryptography, security, timingattack | no comments
Posted by Scott Laird
Thu, 28 Apr 2005 18:20:56 GMT
Phil Windley says that Visa and Mastercard are starting to crack down on small merchants, requiring them to meet some sort of minimum information security standards or lose the ability to accept Visa or Mastercard purchases online. This is clearly a good thing.
He lists 12 basic requirements:
- Install and maintain a working firewall to protect data
- Keep security patches up-to-date
- Protect stored data
- Encrypt data sent across public networks
- Use and regularly update anti-virus software
- Restrict access by “need to know”
- Assign unique ID to each person with computer access
- Don’t use vendor-supplied defaults for passwords and security parameters
- Track all access to data by unique ID
- Regularly test security systems and processes
- Implement and maintain an information security policy
- Restrict physical access to data
The actual questionnaire from Visa goes into a lot more detail (“Do changes to the firewall need authorization and are the changes logged?”). A quick skim of the questionnaire shows a bit of Windows bias (you can’t pass unless you have virus scanners on all your servers–that’s kind of weird in a Unix environment), but it looks like a great step forward. It’s nice to see someone in a position of influence raising the security baseline.
Posted in Computer Security | Tags cryptography, mastercard, security, standards, sysadmin, visa | 1 comment
Posted by Scott Laird
Wed, 16 Feb 2005 19:10:17 GMT
I’m not an expert in cryptography, but I try to pay attention to what’s happening in the crypto world. Today, Bruce Schneier announced:
SHA-1 has been broken. Not a reduced-round version. Not a simplified version. The real thing.
The research team of Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu (mostly from Shandong University in China) have been quietly circulating a paper announcing their results:
- collisions in the the full SHA-1 in 269 hash operations, much less than the brute-force attack of 280 operations based on the hash length.
- collisions in SHA-0 in 239 operations.
- collisions in 58-round SHA-1 in 233 operations
So, unless I’m mis-reading this, SHA-1 lost a factor of 2,048; that’s enough to start moving away from SHA-1, but not enough to run screaming in the streets. The last time that SHA-1 attacks showed up, similar attacks were possible against MD5 and possibly also the newer SHA family members; I’m not really sure if there are cryptographic hashes in common use that aren’t at least slightly tainted right now.
Posted in Computer Security | Tags broken, cryptography, security, sha1 | 5 comments
Posted by Scott Laird
Mon, 25 Oct 2004 15:45:31 GMT
According to The Register, Cisco is currently adding encryption abilities into their phones and call manager software. The article’s kind of hard to follow–it claims that the 7960G currently has encryption support, which is news to me–but the general gist is that they’re planning on adding some sort of direct VPN support into most of their phones via software upgrades.
Knowing Cisco, the feature will be implemented in some odd manner (L2TP+1DES IPsec in the phone?) and will only work with the CallManager-specific SCCP image for the phones, not the SIP image.
On the other hand, if they actually added TLS/SSL support for SIP and SRTP, then that’d be a huge motivation for getting encryption in Asterisk.
Posted in Asterisk | Tags asterisk, cisco, cryptography, security, voip | no comments
