Wednesday November 16, 2005
UltraSPARC T1 & Crypto On the 14th we announced the new UltraSPARC T1 chip. I've had the great privilege of working on and off with the team that developed this since very soon after we aquired some of the technology from Afara.
As should be no surprise the area I've worked in is the cryptographic functionality of the hardware, my team worked very closely with the device driver team that implemented the ncp driver to ensure that the crypto framework was meeting all the needs of the UltraSPARC T1 hardware.
The source for how this works is unfortunately not available in OpenSolaris. The reason for this is that it gives way the information on how to program the crypto functionality on the chip, we aren't hiding this because we want to keep it secret, we would love to make it open source, but because releasing it would change the US export status of the actual hardware. Until we can find away around this the ncp driver is binary only, unfortunately without the ncp driver there is no way to trap through the sun4v hypervisor to get access to the fast crypto.
So for now ncp is in the closed-bins part of OpenSolaris, if things change you can be sure we will move it to the open part of the tree and release the source for how to do this so that other distros can rebuild the ncp driver if the desire.
Technorati Tags: OpenSolaris Solaris SPARC
( Nov 16 2005, 01:45:00 PM GMT ) Permalink Comments [0]
Monday October 24, 2005
Solaris/OpenSolaris Data Encryption Kit I've just added a page to the
OpenSolaris security community describing what the Solaris Data Encryption Kit is and how it impacts OpenSolaris.
Technorati Tag: OpenSolaris
Technorati Tag: Solaris
( Oct 24 2005, 05:07:20 PM BST ) Permalink Comments [1]
Tuesday October 18, 2005
OpenSolaris / Solaris 10 @ RSA Europe 2005 I'm with Glenn Brunette, Dave Walker and Gile Gravier at RSA Europe 2005 conference in Vienna, Austria this week.
This is day two and we have had great intrest in Solaris security features. We have given away several DVDs for Solaris 10. Several people have congratulated Sun on making the source to Solaris available under and open source license.
We have been doing live demos and talking about SMF, Zones and the Cryptographic Framework . In particular our demo is of an SSL enabled (using an SCA-1000 hardware crypto accelerator) Apache server running in a zone using SMF to start it up as an unprivilged user and only the privileges necessary to run. We also have two roles defined, one that can change the Apache configuration and manage the service (but not change if it is enabled on reboot), the other can only restart the service or put it in maintenance mode.
The Europe version of the conference seems to have a little bit of a different atmosphere to the US version. The most obvious thing being I'm there in a suite and tie rather than some Sun branded tshirt.
Also got a possible lead for hardware cryptographic provider for the Cryptographic Framework , that will have another OpenSolaris driver available. Hopefully more on this in a couple of weeks - I can't say anything for sure at the moment.
Technorati Tag: OpenSolaris
Technorati Tag: Solaris
( Oct 18 2005, 04:36:51 PM BST )
Permalink
Comments [0]
Monday September 19, 2005
Can we do better for security of web pages than we do today?
[This text was originaly posted to Sun's internal security community in
response to Radia Perlman asking if we could do better web security, I
thought it was worth sharing my thoughts with the rest of the world ]
One of the things that we really should be trying to stamp out is
allowing otherwise reputable sites to download pages with login screens
over non https connections[1]. Many of them try to justify that the
HTTP POST goes to an https URL but that doesn't matter one tiny bit if
you can't actually be sure the form you entered your details into was
brought to you over a secured transport.
Even then that doesn't really help this type of phishing attack because
it is possible to get hold of certificates from CA's who are the browser
trust anchors and be a "bad guy". A cert only says that the person
managed to prove they are who they said the are, it of course doesn't
say they are nice people. This is the a fundamental problem with
security of web pages, and it is a problem because PKI is too complex to
explain to even the vast majority of computer professionals, so most
people have zero chance of understanding it sufficiently well to
understand the risks.
In my opinion HTML in email is the root cause of most of the recent
phishing and pharming attacks. When all we had was plain ASCII there
was no easy way to hide the real links, people had to cut&paste the URL
into their browser so were a little more aware of what was going on.
Even then though it isn't enough.
However HTML email is here to stay for better or worse. So we need to
find away around this.
I don't believe that DNSSEC is the answer to this for many of the same
reasons that PKI is too complex for people to understand so is DNSSEC.
Whats more it will be along time still before DNSSEC is deployed, even
when it is it will still suffer from the same fundamental problem that
PKI does: it doesn't tell you if a site is a good guy or not. Whats
more this particular attack (and many like it) don't actually involve
DNS anyway since the bad URL contained an IP address.
One thing that everyone always says is user education, teach users not
to click on links in random emails. This isn't going to work in my
opinion, if we don't want links in emails we have to turn back the clock
and not allow HTML email.
Popup dialogs asking the user if they want to trust something are
useless the answer is always yes. For example how many of you just type
yes when using ssh to connect to a machine for the first time ? Have
you ever verified that fingerprint out of band ?
Username/password is a big part of the problem. Sure SSL ensures that
when doing it properly it doesn't go over the network in the clear.
However many people don't ensure the page has come over SSL in the first
place or even if it has it might not actually be from the real site
anyway (see above about popups plus it is really easy to have a cert
that looks like the real sites cert - down to serial numbers and expiry
dates, differing only in the issuer and the public key).
So what can we do about it ?
We need to move away from username/password - even sites that use pseudo
challenge response by asking for parts of a password are vulnerable to
the same MiTM attack over time or if cleverly crafted still in one step.
Whats the options ?
SSL Client side certs ?
I don't think so. That means smartcards everywhere with an applet on the
card that every OS understands and every browser configured to use
smartcards. This isn't going to work for internet cafe's or even the
vast majority of systems out there today. Cards will get lost or
stolen, whats more people are having problems remembering the PIN for
their ATM and credit cards as it is. Chip&PIN isn't actually helping
credit card security that much the thief just needs to look over your
shoulder to get the PIN just before they swipe your wallet with the
card.
Liberty ?
Sad to say but I actually think Liberty might be more part of the
problem than the solution. They way the Liberty protocol works it has
many of the same artifacts in URLs that phishing attacks have
(redirects, big long URLs etc etc). Its a good idea but I don't think
it is solving this problem but a different one of cross
site/domain/realm/company trust.
Kerberos ?
Okay I hear the sniggering, but we have GSSAPI (and thus Kerberos)
support in Mozilla/Firefox, Internet Explorer (and I think Safari) as
well as server side support in Apache and MS IIS (and it is coming to
the JES webserver too), so the technology is out there.
But Kerberos is hard to deploy you say ? Is it ? Is it really
any harder than PKI ? You can lookup which realm (and which KDC to talk
to) a given host is in using DNS (which is where DNSSEC does become
important). Kerberos can do cross realm better than the PKI solutions
we have in our browsers today.
Unfortunately Kerberos config is per host on all systems I've looked at
so that doesn't really help end users and certainly doesn't help the
internet cafe case.
Whats the name of that thing that many people carry around all the time,
even when at work and in internet cafes ? Oh yeah a cell/mobile
phone.
Surely there is something we can do with SMS. Google is using SMS
messaging to stop mass spam sign up for GMail ?
One of the advantages of how cell/mobile phones caller id and SMS sender
id works is that you only see the phone number. This means the user
picks the name and any SMS that comes from a number alone is obviously
from somebody you don't know. So you would pre program your
bank/ebay/paypay numbers into your phone. They send you a challenge SMS
when you visit their site and you reply to that SMS with a response. Out
of band authentication.
Unfortunately it won't work because cell coverage isn't good enough and
SMS isn't actually quick enough.
However Java is starting to become quite common on mobile phones and in
many systems there is a smartcard in the phone already (though most
people know it as a SIM), so we could have some safeword or securid
applet on our phones that doesn't need coverage to the network to work,
it could be tied to the SIM somehow as part of identifying it is you.
It needs to be really really simple though and this is where the securid
model probably works better - just look at the number and type it in as
you see it (sure safeword is more secure but we need simple)
Problem though would be deployment of this and scaling it on the phone
to work for more than one or two sites.
I don't have any other suggestions at the moment, but I have plenty of
other possible attacks and problems that come up with HTML based
interfaces and our continued march to use them for admin interfaces [
none of which are solved by any of the above ].
One of the responses I got from Nico Williams
was to have a look at TrustBarfor Firefox/Mozilla.
This looks like a good approach, however it only helps if you have control over your
browser - it really doesn't help at all in an internet cafe
Tuesday August 09, 2005
OpenSolaris Security Community
The OpenSolaris Security Community is now live. There is some skeleton content there just now. We will be adding more as time goes on, particularly in the area of active project work and pre integration source for these.
There is also now a security-discuss mailing list.
Technorati Tag: OpenSolaris
Technorati Tag: Solaris
Wednesday July 13, 2005
Good article on the value of Trust Anchors I came across this article by Dr. Colin Walter of Comodo today. It is a good read, and to me it is the single most important thing about using SSL to do buisness on the internet. You have to have a high level of assurance in your Trust anchors and trust that they are doing everything in their power to authenticate and verify the entities that they issue certificates to.
In the interests of full disclosure I will point out that my wife used to work for VeriSign/Thawte doing the very job that this article points out is so very important - ie going beyond simple domain possesion and doing real authenitcation and verification. However I was of that opinion even before my wife did that job but it was very encouraging to learn from her how hard it actually is to get a cert for VeriSign or Thawte.
The sad thing is though that there is no realistic way even for security aware people to use the common web browsers in such away that they can easily make value judgements about the site based on its cert, why ? Because all the default browser trust anchors are treated equally even though they aren't equal in the level of assurance they provide, whats more some (eg VeriSign) even provide multiple levels of trust depending on how much the certificate cost but the browser doesn't give the user that information (yes you can find it but doing so is way beyond the skills of even many computer experts, it requires a deep understanding of PKI and of the particular policies of the CAs).
( Jul 13 2005, 12:37:27 AM BST )
Permalink
Comments [0]
Friday July 01, 2005
Signed Solaris 10 binaries ? You may have heared by now that Solaris 10 has signed binaries, you probably have questions about what this really means. I was one of the engineers who designed and developed the framework that made this possible.
What is it NOT ?
It is not an attempt to lock out 3rd party kernel module or other code from running on Solaris or OpenSolaris distributions. In fact it isn't really intended for use by Sun at all, with one exception that applies to Solaris the binary product but not OpenSolaris (this is a US export requirement because at the time of development of Solaris 10 we couldn't claim it was opens source - we still can't but we should be able to for future releases), it is really intended for use by the end administrator.
Okay so what is it then
Kernel modules, libraries and compiled programs are represented in as ELF objects in Solaris (and in many other UNIX systems too). The ELF object contains many things in addition to the text and data sections that actually describe the program code. For example an ELF object may contain debug information or a comments section that is information about revision history, it also contains information for the linker/loader.
We exploit the fact that ELF is exensible and use that to hold a cryptographic signature of the parts of the ELF object that impact the running program code, basically any ELF section that is marked that it will be taken into memory (eg. SHT_PROGBITS). We make an RSA signed SHA-1 hash of those bits and store it in a new ELF section. You do this using a new program called elfsign(1), it is in the SUNWtoo package.
At this time elfsign(1) takes a raw key and certificate from a file, but will soon (planned for a Solaris 10 update release) have the ability to take it from an PKCS#11 token that is available via the Solaris Cryptographic Framework.
So what do you do with these signatures then ?
As of the initial release of Solaris 10, for the most part nothing happens with them unless the admin explicitly askes for verification of a paritcular binary, for example:
$ elfsign verify -e /lib/libc.so.1 elfsign: verification of /lib/libc.so.1 passed. $ elfsign verify -e /usr/bin/vi elfsign: verification of /usr/bin/vi passed. $ elfsign verify -e /kernel/genunix elfsign: verification of /kernel/genunix passed.The one exception to this where the system will require verification of an ELF object before using it is for Solaris Cryptographic Framework plugins (user & kernel). Sun was required to do this due to US Export Law, OpenSolaris should not be bound by this requirement since it is open source.
Can I sign my own stuff ?
Yes you can, unfortunately though we didn't have time to make the elfsign(1) commands as user friendly for this part as we had hoped. This will be easier to use in the future. This was because the request sub command of the elfsign(1) command was originaly designed just for use by people signing cryptographic providers and as such asks some questions and creates a certificate request that isn't appropriate for the general case.
I can deal with that just tell me what to type to get a key and certificate
Okay here goes but I did say this wasn't going to be pretty just now...
$ elfsign request -k mykey -r newreq.pem Enter Company Name / Stock Symbol or some other globally unique identifier. This will be the prefix of the Certificate DN:Enter anything in there we are going to change it later anyway, then answer 'n' to the next two questions. If you have a real Certificate Authority already then you can send that request to them, note to them that the request DN will look a bit strange and should be changed to match your local policy. If you don't have one setup or don't want to use it then follow the instructions below to create a local CA using OpenSSL.
$ mkdir demoCA $ cp /etc/sfw/openssl/openssl.cnf demoCAEdit the following _default values to match your organisation, I recommend just leaving the country and state ones blank, eg:
countryName_default = stateOrProvinceName_default = 0.organizationName_default = Example Sun ISV LtdNow create your local CA:
$ export SSLEAY_CONFIG=demoCA/openssl.cnf $ perl /usr/sfw/bin/CA.pl -newcaJust take the default answer for everything, other than the passphrase why you need to give one longer than 4 chars in length. Once that is done we can use this new CA to sign the request we generated above.
I've got a key and cert how do I sign now ?
This part is easy and is intended to be easily integrated into your existing build system, (probably in a Makefile or as part of your release engineering process):$ elfsign sign -k mykey -c mycert -e libmystuff.so.1Thats it signed! In order for the verify subcommand of elfsign(1) to work you need to put the certificate into /etc/certs. Any name that isn't already taken will do since the name of the file is not significant.
$ cp mycert /etc/certs/Example_ISV_LtdYou should now be able to do this:
$ elfsign verify -e libmystuff.so.1 elfsign: verification of /lib/libc.so.1 passed.To be sure it all worked I recommend copying the signed binary and cert to a completely different system.
Technorati Tag: OpenSolaris
Technorati Tag: Solaris
