I’m afraid I only got to one session in the afternoon, but I have some good interviews coming your way in exchange!
User Authentication For Winners!
I didn’t get to attend but I know that Karthik’s talk on writing a user auth system was good, here are the slides. When we were at NI he had to write the login/password/reset system for our product and we were aghast that there was no project out there to use, you just had to roll your own in an area where there are so many lurking security flaws. He talks about his journey and you should read it!
AWS CloudHSM And Why It Can Revolutionize Cloud
Oleg Gryb (@oleggryb), security architect at Intuit, and Todd Cignettei, Sr. Product Manager with AWS Security.
Oleg says: There are commonly held concerns about cloud security – key management, legal liability, data sovereignty and access, unknown security policies and processes…
CloudHSM makes objects in partitions not accessible by the cloud provider. It provides multiple layers of security.
[Ed. What is HSM? I didn’t know and he didn’t say. Here’s what Wikipedia says.]
Luckily, Todd gets up and tells us about the HSM, or Hardware Security Module. It’s a purpose built appliance designed to protect key material and perform secure cryptographic operations. The SafeNet Luna SA HSM has different roles – appliance administrator, security officer. It’s all super certified and if tampered with blows up the keys.
AWS is providing dedicated access to SafeNet Luna SA HSM appliances. They are physically in AWS datacenters and in your VPC. You control the keys; they manage the hardware but they can’t see your goodies. And you do your crypto operations there. Here’s the AWS page on CloudHSM.
They are already integrated with various software and APIs like Java JCA/JCE.
It’s being used to encrypt digital content, DRM, securing financial transactions (root of trust for PKI), db encryption, digital signatures for real estate transactions, mobile payments.
Back to Oleg. With the HSM, there’s some manual steps you need to do, Initialize the HSM, configure a server and generate server side certs, generate a client cert on each client, scp the public portion to the server to register it.
Normal client cert generation requires an IP, which in the cloud is lame. You can isntead use a generic client name and use the same one on all systems.
You put their LunaProvider,jar in your Java CLASSPATH and add the provider to java/security and you’re good to go.
Making a Luna HA array is very important of course. If you get two you can group them up.
Suggested architecture – they ahve to run in a VPC. “You want to put on Internet? Is crazy idea! Never!”
Crypto doesn’t solve your problem, it just moves it to another place. How do you get the secrets onto your instances? When your instance starts, you don’t want those creds in S3 or the AMI…
So at instance bootstrap, send a request to a server in an internal DC with IP, instance ID, public and local hostanmes, reservation ID, instance type… Validate using the API including instance start time, validate role, etc. and then pass it back. Check for dupes. This isn’t perfect but what are ya gonna do? You can assign a policy to a role and have an instance profile it uses.
He has written a Python tool to help automate this, you can get it at http://sf.net/p/lunamech.