Slashdot Mirror
Hardware Crypto Support In OpenBSD
"Further work will now happen. We wish to support other products (ie. IRE, Bluesteelnet, perhaps even 3COM or PCC-ISES if they would open their minds). Some crypto chip vendors are being extremely friendly to us. If anyone wants to help write drivers, get in touch."
We also hope to add more parts to our cryptography framework so that it can supply RSA/DSA type operations for chips that support that, so that OpenSSL can use the framework, and thus enhancing everything from https to ssh performance. We have grand schemes in mind."
"If you order a card from www.powercrypt.com, tell them you intend to use it with OpenBSD. I have heard rumours they are allowed to export it."
"Most of this work was done by Jason Wright and Angelos Keromytis."
If by ATM, you mean "Automated Teller", the vast majority of ATM's still use single length DES keys. I work in the industry, and I am not aware of any large scale deployment of triple-DES ATMs.
Linux monkeys, please stay in your cages. Thank you.
Why are you telling me to grow up?
I didn't slam Linux. I don't see much of a reason to slam it anyways.
So why is it ok to slam BSD? That's (Linux) advocacy taken too far. It is not really not funny, yet I'm sure it will continued to get moderated way us as funny.
This is advocacy gone wrong.
Some of the posts a misunderstanding between what is being annouced (hardware accleration) as opposed to the traditional hardware security modules (often known as a "HSM", the type FIPS 140 adresses). Hardware acceleration is a very useful feature, but true a HSM is much more difficult to achieve. A good example of a cheap HSM is chipcard.
) . Keep a couple of things in mind when reading the PKCS11 documents:
The HSM has to provide both physical and logical security. Real world costs force a cheap HSM to skimp on physical security, but there is no good excuse for poor logical security. Logical security is much easier to acheive if you keep the functionality simple. As you add more features (IPSEC and SSL and SSH), it starts getting very complicated.
One post suggested a "cheap" solution of an FPGA and internal-read-only registers to store keys. That only brushes the surface. Here are some other potential issues:
* Control access for "writing keys"
* Controls for functionality (limit who can perform certain actions
* Figure out how to import and export existing keys in a secure manner.
* Make sure that keys are tied to their appropriate function (i.e. can't use a SSL key to perform IPSEC functionality).
* Provide assistance to the hardware in resisting attacks (timing, power, etc.).
* Provide for a method of securly updating functionality without revealing internal data.
Since I do software design, and have a good hardware group, I tend to think the logical security is the most interesting part. If you would like to find out more about this, try taking a look at an implementation: the PKCS #11 (http://www.rsasecurity.com/rsalabs/pkcs/pkcs-11/
1) PKCS #11 is designed for "client" security tokens - like smart cards. A number of Certificate Authority vendors are using it for servers, but it does not work that well. Activating special features by sending passwords in the clear may make sense for a smartcard, but is a real problem when you are worried about insider-fraud.
2) PKCS #11 is very flexible, and can be misconfigured. Just because you are following the PKCS #11 "standard" does not mean you have a secure implementation.
The FIPS 140 standards are a little more difficult to read. But skimming over these will give you an idea of the things that can go wrong. Remember, your security is only as good as the weakest link!
AltiVec can accelerate any block cipher. In fact one of the purposes of AltiVec envisioned by Motorola was for VPNs
Don't be a bigot.
/. on the LinVideo/"legal" Linux DVD player).
Hey, his statement is better than Linus's being a play-thing for corporate products (see
Better than the Linux hackers that were so sure of themselves during the MindCraft fiasco, hemming, hawing, and touting their code as better. Hell, articles picked up on it, they touted themselves as such in public, and during the re-run of the testing. Then they go themselves proved utterly wrong. Guess what? Linux's networking code STILL sucks months later.
Your fooling yourself if you think this is a BSD mentality. It's a common human trait that occurs in many people. Don't think you're better than others. He's touting his accomplishments, and that IS the truth. Good code is good code. Suck it up.
--
Say LIE NUX: it's more representative of their community and the OS--it has the word "Lie" in it and rhymes with the "Sucks".
Not likely. The folks at Intel are totally anal about releasing specs to the open source community.
--Louis (louis at spamthis signalpath dot on dot ca)
Just like DVD, code on the CD or even programs installed on your hard drive will be encrypted and region coded. Your CPU of the future will also have a region code assigned to it. Code will be decoded on the fly inside the CPU just before execution. US software won't run in Singapore, etc. And export controls on CPUs can remain strong because it's not about crypto. It's about exporting high-tech. Remember, that Chinese guy busted on espionage for stuff like this? The warez/piracy problem will be solved by dividing the world into 32 incompatible regions. Even compilers can be made to produce region locked code. PH3@R the future. I know I do.
Probably not. Distributed is trying to crack RC5-64 currently, and this chip doesn't do RC5 (I can't think of anything offhand that does that in hardware).
-lee
There's a difference between open and free bsd there, dude.. And sure, Solaris has had it all for quite some time, but if you don't want to pay assloads of cash for the hardware, you want some other options. I'm sure FreeBSD will get this hardware crypto support soon, so you have your SMP support there.
Now sure, for huge compute apps, there's no intel boxes beating a sun or digital machine, but just use the right tool for the job, yes?
cheers,
-o
Why are you posting anonymously? You seem to have some strong feeling about all this, and speak like an authority. "Debunking" this and that.. Man. Nobody is going to give anonymous coward a job..
I don't understand how you can say that an audit does not cause less bugs. The only way that could be is if you induce bugs during the audit. Huh? Do you think the OpenBSD guys are completely incompetant?
And secure by default is just that. Sure, a good admin can make either BSD or Linux secure or insecure. But our of the box is out of the box. How many remote root exploits are there for RedHat? How many for OpenBSD? I'm not giving numbers, but I can guarantee that OpenBSD is LESS.
Geez, kids these days..
-o
BSD is cool because it does some things in a way I prefer to the linux way. Linux does some things I prefer to the BSD way.
I think both sides could benefit from looking more closely at the best of what 'the competition' has to offer.
How useful is hardware encryption? How does it compare in speed and, more importantly, price/performance to software ecryption? 600+ MHz CPUs are pretty cheap these days, so wouldn't it make more sence to buy a second CPU instead of the crypto card?
___
___
If you think big enough, you'll never have to do it.
Hardware has two advatages. 1) it is generally faster. 2) It is harder to trojan a hardware device then software. The first one is all that most people think about.
(disclaimer: I like both linux and bsd, and a number of other os's. I just found the post funny). :)[/sarcasm] :)
[sarcasm]Of course, the linux developers are NEVER proud of their work, are they?
dude, get over yourself
Commodore 64, Loading up the dance floor!
Wow, could I really kick ass on distributed.net if I got one of these puppies? If so, I'm all over it! :)
-Waldo
Mocking quote:
99% of the Linuxers who slam linux installed NT in 1997, and switched to Linux in 1999 when NT got too popular. Now they need some reason to justify their move, other than "I don't feel 31337 using NT anymore."
The other 1% had their dog run over by Bill Gates when they were younger.
Believe it or not, just because people make choices different from yours, doesn't mean they aren't making them on a rational basis. Right now I use linux as a desktop unix, but if I were to administer a server openbsd would be high on my list of operating systems to consider.
Scuttlemonkey is a troll
99% of the BSDers who slam linux installed linux is 1997, and switched to BSD in 1999 when linux got too popular. Now they need some reason to justify their move, other than "I don't feel 31337 using linux anymore."
The other 1% had their dog run over by linus torvalds when they were younger.
heh. believe it or not, some people have a sense of humor. I love it when this flamewar comes up because it gets so ridiculous so quickly.
typing this on a SMP linux box, through an openbsd nat/firewall.
of course, my mocking post was funnier, so neener neener!
Miguel may be a man I have a lot of respect for as a great coder. He's the man of Gnome. He just doesn't have much of a grasp on Distro issues. He has the idea that the second a stable piece of code releases the hands of the developers, it should be in distros. The turnover time is a little longer then that. He's also said that Debian packages are 'too hard' and so Helix didn't ship deb's with their recent Gnome Preview.
That doesn't mean I'm mad at him. He just doesn't understand. Give him a chance, be rational. He's a good coder, just maybe a little naive.
I'm not a crypto-head by any means, and I don't really follow IPSec stuff or anything. But, I'm gonna offer my completely uninformed opinion anyway. :)
Seems to me like this would be good hardware to put in a bridgehead router... particularly with software/drivers to opportunistically encrypt IP traffic between routers that support it. I don't know how far away we are from this, but I think this is the goal. Transparent end-to-end opportunistic encryption. Yee ha.
Its really not a matter of having anything secret to protect, either, it's more a matter of wheat and chaff... as much encrypted traffic the better. And besides, it helps to obfuscate brain damaged plain-text password protocols.
I think this rocks.
What, the world of people with names who know what they're talking about?
Zurk: OpenBSD had a root exploit
Smart person: no it didn't
Zurk: OpenSSH had a root exploit
Smart person: no it didn't
Zurk: RSAREF had a root exploit
I will use short words to get this through to you: RSAREF is not part of OpenSSH. RSAREF is not part of OpenBSD. RSA is a code that men own. You must pay these men to use RSA. You can use RSA and not pay if you use RSAREF. RSAREF is a code that has a bug that we can not fix. The bug that is in RSAREF is not our bug! It is the bug of the men who own RSA! Those men will not fix it since no one pays for RSAREF. This bug is with us till late this fall. Then we can use RSA that is not RSAREF and still not pay.
Clear?
umm..i hate to burst your fantasy but -
BSD doesnt support more than one CPU.
Solaris is the #1 ecommerce platform becuase its more reliable and scalable than almost anything else...including linux.
Hardware crypto support for SSL has been around a long time in linux, NT and solaris on apache, netscape enterprise and every other webserver. just ask nfast.
umm...ssh exploit anyone ? yes, openssh was vulnerable to it. theo's released a few patches for the current version of openBSD too.
umm..*cough* *cough*
here's something interesting :
openssh:
Even though the OpenSSH code checks all input parameters carefully,
internal RSAREF functions can still overflow.
from : http://www.openbsd.org/advisories/sslUSA
3DES. Your ATM's favorite cypher.
HAHAHA, you're funny.
Cryptography is a very important issue to EVERYONE, especially with the amount of digital information being passed around(be it on internal or external networks).
Cryptography is used to protect your credit card numbers, your confidential personal records held by schools. hospitals, and government agencies, and to protect your machine from foreign espienage(sp?).
This is *definitely* "news for nerds". I just think you're a troll( I wish I had some points ).
I sure as hell wouldn't want my credit card number floating around in clear text... how about you?
I swear, you anonymous cowards need to get a clue. Lots of people would use this encryption( besides pedophiles anyway). Think about credit card companies, and schools, and hospitals.
They all need encryption. And this helps alot!
I really think the anonymous coward status should go away!
Does anyone support the security chip on the Intel NICs?
Now what exactly do userland tools have to do with Linux having security problems. Those are the userland tool problems, retardo. More BSD faggots trying to obfuscate the issues. That's why you guys are losers. So then userland tools have nothing to do with security? I never made an personal attack on you or did i say something wrong like "Linux sucks." I should just leave the 14 year olds to their rpm problems.
Funny how this bit of ignorance comes from one of the largest penguins out there. Miguel de Icaza! Miguel's Incompetence
Miguel is wrong.
I never find core files for the stock OpenBSD binaries.
When bash.core stops being found, perhaps he can make some claims.
When they stop having security holes, perhaps they can start to claim that their userland tools are non-ancient.
When they stop calling mktemp(), inet_addr(), and strcpy, then perhaps they can start to claim something like that. Their source code is unmaintained. Theo's response
And a software implementation of SSL in Netscape works just fine for my credit card numbers (like there's an alternative for buying something online anyway?)
As for address/phone number, I feel like the cat is more or less out of the bag on that one. I haven't tried myself, but I wouldn't be surprised if it were easy to look those up.
overall, and as much of a misanthrope as I am, I just haven't felt like much of anyone is out to get me, electronically at least ;)
And I can't think of a whole lot of personal info about myself, that I keep outside my head, that I feel like I don't want others to know about.
I enjoyed your joke about the tinman, if I understood it.
but I can't think of a good reason to be the "tinman" (secure my linux box that or run OpenBSD, encrypt all my data, etc.) other than that it would be fun and educational (which, I admit, might be reason enough)
-------------------- the list is long. dirac angestung gesept
but wait... I don't have anything to encrypt... or decrypt. guess I better find something appropriately shady to do to justify that kind of protection.
much as I want to reserve the right to have the kind of secrecy strong crypto might permit, I can't think of anything I want to hide that badly. any suggestions?
<sarcastic> if only I was a secret agent or something </sarcastic>
-------------------- the list is long. dirac angestung gesept
I guess what I really meant was: If I can do Twofish at >100Mbps in software, I see a lot less need for hardware implementations.
In a word? nope.
VPNs only protect traffic as it traverses from one VPN gateway to the other. (or host if the VPN is host-based) Before the first gateway and after the last gateway the traffic is susceptible to any and all forms of network attack/abuse. AFAIK, VPN gateways do no massaging of packets in order to attempt to make them less dangerous - it just encapsulates them (AH/ESP...) and sends them on their way.
Irregardless...
This also includes sniffing, which is certainly enough reason to not use insecure authentication protocols.
sedawkgrep
Is that a salami in my pants or am I just happy to be me?
This is slightly offtopic... we're building a large scale site thats expected to handle 180k pages an hour, the majority of them encrypted with SSL. Our server platform is Solaris, but even with load balancing, I think the servers will choke on this much SSL :)
Does anybody have any experiences with using this kind of solution? and are there any export restrictions etc on the hardware (our company is in the UK)? I'm a little fuzzy about whether the key strength is determined by the hardware, or the software controlling it.
We most probably will use Apache, but NS Enterprise is also an option.
Yahoo! have a category devoted to this stuff, but I didn't know where to start.
Except that I can't find out how DES was developed. Oh sure I have the source, but it contains tables and tables and tables of magic numbers! The choice of the values for the S boxes and why and how those choices were made is **still** classified! Why? In the interests of my own security, I have no choice but to assume that it was to leave in some weak back door to the data that Feds (and any h4xx0r who stumbles upon the same trick) can quickly exploit at any time.
The problem is that nothing else is as well-explored; all of the "NSA-safe" algorithms are too new to have been properly dug through.
But at least other algorithms *can* be explored. There's no magic unexplainable source code in there. And I trust many crypto experts around the globe saying [crypto-method] is secure based on examining the algorithm than I do the gov't telling me DES is secure "because we say it's secure but won't tell you why". Besides, the DOJ/FBI never did crack Kevin Mitnick's blowfished files. And for that, they refuse to return his equipment to him on the grounds that it "might" (excuse me?) contain illegally obtained data.
In browsing the web sites mentioned, I don't see pricing/availability info on the actual hardware, only mention that "we OEM."
Are there vendors actually selling these in "consumer" quantities?
If you're not part of the solution, you're part of the precipitate.
Except that I can't find out how DES was developed. Oh sure I have the source, but it contains tables and tables and tables of magic numbers! The choice of the values for the S boxes and why and how those choices were made is **still** classified! That's true, and should have an impact on the decision process -- but again, we've been eyeballing those S-boxes for a LONG time, and we've found a lot of their characteristics -- and all of them we've found so far indicate that they're _strong_, not weak. But at least other algorithms *can* be explored. There's no magic unexplainable source code in there. Now, what would make you say _that_? The fact that you haven't studied crypto? _All_ of the other algorithms contain incompletely understood mathematics. Even RC4, a model of beauty, simplicity, and NO magic numbers, is a black box mathematically. And I trust many crypto experts around the globe saying [crypto-method] is secure based on examining the algorithm Ahem. Fire them. All of them. Any crypto expert telling you an algorithm is "secure" is LYING. Okay, there's ONE exception: one-time-pad. And that's impractical. than I do the gov't telling me DES is secure "because we say it's secure but won't tell you why" Well, they don't do that -- but there _are_ hundreds and even thousands of cryptographers who have focussed on DES for years and years, and who have found not only no holes, but have found that holes which are present in other similar algorithms are absent in DES. Besides, the DOJ/FBI never did crack Kevin Mitnick's blowfished files. If they had a secret method for craching DES, would they have admitted it? Certainly not. Blowfish is more likely, since admitting that wouldn't collapse the banking system, but it's still unlikely, since if they can crack it they'll want to save the secrecy for someone they don't have control over. Mitnick is nothing. -Billy
When the diffrential-cryptoanalsis attack came out in the mid-90s DES was one of the few cyphers that were extreamly resistant to it. DES with the old pre-NSA-change S-Boxes was very weak against the "new" attack.
There were many people who beleved that
There is no reason to beleve that the S-Box change made DES weaker. The again there is no reason to beleve that it didn't. Or wasn't breakable by some other means the NSA knew about, and they wanted to fix the S-Boxes because they thought some other goverment knew how to attack them.
It's a hard field to make a right choice in, only in part because paranoia is actually a good mindset to be in when doing crypto think. I beleve 3DES is relitavly safe. But I don't know. I'll feel much better after we have 5+ years of experiance with whatever cypher wins the AES selection process.
If your network link is encrypted, is there any reason for encrypted applications like ssh, https, and friends? It seems the answer would be no, but I'm not an expert.
SSLv2, SSLv3 and TLS all support DES and 3DES (according to the installed ciphers in my copy of Opera 3.62 on Windows). So this chip will help with this bit of SSL, once the initial key exchange stuff is done; no doubt an accelerator that supported the key exchanges better would be faster.
This would be a good chip to use for IPSec VPNs with pre-shared keys - OpenBSD comes with IPSec as standard these days, so it could make a nice firewall/VPN gateway combo. I believe quite a few router manufacturers use Hi/fn chips, so it should be fairly good.
I've always wanted a encryptor/decryptor board that is a huge FPGA or similar with a PCI busmaster interface. It would be better if it could hold a large number of differnt keys that the OS then can control the setting and use of. The key space would be write only memory so they can't be read back by any process. Only written to. The board would operate in burst mode when takling on the PCI bus. It would transfer in a block of memory, encrypt it, then burst mode transfer it out. It's operation would be much like a DMA controller, but with the encryption added in. By using a FPGA one can change the programming of the board as new methods come out. One would need a program protect jumper, but that is easy to do.
This won't help SSL because SSL uses a different
type of crypto made of up several parts.
SSL can use DES (not DES-3 but a DES-3 engine should be able to do DES). SSL also uses MD5 and SHA which this device can do so maybe that would help some. The chip does not do the public key things that are required for cert signing and inital key exchange. Once the keys have been exchanged the hardware might be able to speed up some of the other bits but the overhead to talk to the card may be more than its worth.
Yeah...that would almost be as bad as giving your credit card to, say, a waiter or something where they can take it away and look at it!
I'm just kidding, but I find it kind of interesting that people are willing to hand the piece of plastic over the several people each day, but not transmit it in the clear over the net, where it's far less likely anyone is looking. I say, if you're going to be anal about your credit card numbers, you should be anal in all situations. Of course, that would make it nearly impossible to use the things. Catch 22? Who knows...
IPSec can tell you what machine you're talking to, but not which user AFAIK. So it isn't as powerful as ssh's RSA authentication or SSL client certificates.
Will these crypto chips still be a good idea when AES comes out? It's going to be much faster than 3DES.
3DES is not known to have exploitable weaknesses. If you have a choice between 3DES and anything else, the current choice is 3DES.
The problem is that nothing else is as well-explored; all of the "NSA-safe" algorithms are too new to have been properly dug through.
I personally like RC4 more than DES-type algorithms, but it's even less understood. Twofish is an impressive algorithm as well, but again, its review process has only started. When (if) it becomes AES, then it'll have enough attacks to make it worth considering.
-Billy
The sad part is, even in meta-moderation these mismoderated points won't be corrected. If they hate BSD while moderating, why would their friends who are meta-moderating be any different
Because metamoderation involves random selection rather than self-selection. Only people "interested" in BSD (or Hi/fn, or HW encryption) will be attracted to this story, and unfortunately there are simply more people negatively than positively interested right now. Hopefully, the random selection involved in metamoderation will result in a more "disinterested" (i.e. impartial) group of people.
-Billy
This particular chip (Hi/fn 7751) was designed and tested to accelerate SSL, so I suspect it won't have a problem there. I've put a couple of million SSL packets through it (give or take a million, who's counting).
-Billy
This would give the BSD's more ground on large
e-commerce websites, since hardware crypto is usually used when you need to reduce the load
on a loaded ssl server. I say the BSD's because this is likely to be ported over to the rest too
Cool...
FreeBSD.... The Daemon Made me do it
Further work will now happen. We wish to support other products (ie. IRE, Bluesteelnet, perhaps even 3COM or PCC-ISES if they would open their minds). Some crypto chip vendors are being extremely friendly to us. If anyone wants to help write drivers, get in touch.
In case anyone cares, specs for the VLSI (Philips) VSC115 are published. Pretty nice performance specs. The official policy is to support Linux driver development for new products, but the details are still in the works and BSD is (alas) not a priority.
Lacking <sarcasm> tags,
there are press releases talking about this on the Hi/fn press release page.
how long, do you suppose, before someone makes a keyboard that ssh's (or use some equivalent measure to encrypt all traffic between the keyboard and computer) to the computer, so that the truly paranoid can feel a little less worried about someone planting a KeyGhost on a machine when they're not looking? or is that way too paranoid?
-------------------- the list is long. dirac angestung gesept