OK, it’s been out a couple of months now with the usual “ZOMG it’s RealID all over again” worry-mongers raising their heads.

So we’re going to go through what NSTIC is and isn’t and some “colorful” (or “off-color” depending on your opinion) use cases for how I would (hypothetically, of course) use an Identity Provider under NSTIC.

The Future Looks Oddly Like the Past

There are already identity providers out there doing part of NSTIC: Google Authenticator, Microsoft Passport, FaceBook Connect, even OpenID fits into part of the ecosystem.  My first reaction after reading the NSTIC plan was that the Government was letting the pioneers in the online identity space take all the arrows and then swoop in to save the day with a standardized plan for the providers to do what they’ve been doing all along and to give them some compatibility.  I was partially right, NSTIC is the Government looking at what already exists out in the market and helping to grow those capabilities by providing some support as far as standardizations and community management.  And that’s the plan all along, but it makes sense: would you rather have experts build the basic system and then have the Government adopt the core pieces as the technology standard or would you like to have the Government clean-room a standard and a certification scheme and push it out there for people to use?

Not RealID Not RealID Not RealID

Many people think that NSTIC is RealID by another name.  Aaron Titus did a pretty good job at debunking some of these hasty conclusions.  The interesting thing about NSTIC for me is that the users can pick which identity or persona that they use for a particular use.  In that sense, it actually gives the public a better set of tools for determining how they are represented online and ways to keep these personas separate.  For those of you who haven’t seen some of the organizations that were consulted on NSTIC, their numbers include the EFF and the Center for Democracy and Technology (BTW, donate some money to both of them, please).  A primary goal of NSTIC is to help website owners verify that their users are who they say they are and yet give users a set of privacy controls.

Stick in the Mud photo by jurvetson.

Now on to the use cases, I hope you like them:

I have a computer at home.  I go to many websites where I have my public persona, Rybolov the Hero, the Defender of all Things Good and Just.  That’s the identity that I use to log into my official FaceBook account, use teh Twitters, log into LinkedIn–basically any social networking and blog stuff where I want people to think I’m a good guy.

Then I use a separate, non-publicized NSTIC identity to do all of my online banking.  That way, if somebody manages to “gank” one of my social networking accounts, they don’t get any money from me.  If I want to get really paranoid, I can use a separate NSTIC ID for each account.

At night, I go creeping around trolling on the Intertubes.  Because I don’t want my “Dudley Do-Right” persona to be sullied by my dark, emoting, impish underbelly or to get an identity “pwned” that gives access to my bank accounts, I use the “Rybolov the Troll” NSTIC  ID.  Or hey, I go without using a NSTIC ID at all.  Or I use an identity from an identity provider in a region *cough Europe cough* that has stronger privacy regulations and is a couple of jurisdiction hops away but is still compatible with NSTIC-enabled sites because of standards.

Keys to Success for NSTIC:

Internet users have a choice: You pick how you present yourself to the site.

Website owners have a choice: You pick the NSTIC ID providers that you support.

Standards: NIST just formalizes and adopts the existing standards so that they’re not controlled by one party.  They use the word “ecosystem” in the NSTIC description a lot for a reason.

• Bacn–It’s Cooked Spam
• NIST Cloud Conference Recap
• LOLCATS and NSTIC
• When Standards Aren’t Good Enough
• More on Georgia’s FISMA Reporting

Interesting blog post on Microsoft’s TechNet, but the real gem is the case filing and summary from the DoJ (usual .pdf caveat applies).  Basically the Reader’s Digest Condensed Version is that the Department of Interior awarded a cloud services contract to Microsoft for email.  The award was protested by Google for a wide variety of reasons, you can go read the full thing for all the whinging.

But this is the interesting thing to me even though it’s mostly tangential to the award protest:

• Google has an ATO under SP 800-37 from GSA for its Google Apps Premiere.
• Google represents Google Apps for Government as having an ATO which, even though 99% of the security controls could be the same, is inaccurate as presented.
• DOI rejected Google’s cloud because it had state and local (sidenote: does this include tribes?) tenants which might not have the same level of “security astuteness” as DOI.  Basically what they’re saying here is that if one of the tenants on Google’s cloud doesn’t know how to secure their data, it affects all the tenants.

So this is where I start thinking.  I thunk until my thinker was sore, and these are the conclusions I came to:

• There is no such thing as “FISMA Certification”, there is a risk acceptance process for each cloud tenant.  Cloud providers make assertions of what common controls that they have built across all
• Most people don’t understand what FISMA really means.  This is no shocker.
• For the purposes of this award protest, the security bits do not matter because
• This could all be solved in the wonk way by Google getting an ATO on their entire infrastructure and then no matter what product offerings they add on top of it, they just have to roll it into the “Master ATO”.
• Even if the cloud infrastructure has an ATO, you still have to authorize the implementation on top of it given the types of data and the implementation details of your particular slice of that cloud.

And then there’s the “back story” consisting of the Cobell case and how Interior was disconnected from the Internet several times and for several years.  The Rybolov interpretation is that if Google’s government cloud potentially has tribes as a tenant, it increases the risk (both data security and just plain politically) to Interior beyond what they are willing to accept.

Obligatory Cloud photo by jonicdao.

• Reinventing FedRAMP
• NIST Cloud Conference Recap
• Coming Soon to a Cloud Near You…
• How to Not Let FISMA Become a Paperwork Exercise
• FedRAMP: It’s Here but Not Yet Here

Ref: NSTIC
Ref: On the Internet…

• Realistic NSTIC
• Et Tu, TIC?
• Hackers, Protesters, Iran, Twitter, and Lolcats
• Cyberlolcats Watch the Hackers at DefCon
• LOLCATS and Hackable Coffee Pots

You should have seen Special Publication 800-39 (PDF file, also check out more info on Fismapedia.org) out by now.  Dan Philpott and I just taught a class on understanding the document and how it affects security managers out them doing their job on a daily basis.  While the information is still fresh in my head, I thought I would jot down some notes that might help everybody else.

The Good:

NIST is doing some good stuff here trying to get IT Security and Information Assurance out of the “It’s the CISO’s problem, I have effectively outsourced any responsibility through the org chart” and into more of what DoD calls “mission assurance”.  IE, how do we go from point-in-time vulnerabilities (ie, things that can be scored with CVSS or tested through Security Test and Evaluation) to briefing executives on what the risk is to their organization (Department, Agency, or even business) coming from IT security problems.  It lays out an organization-wide risk management process and a framework (layer cakes within layer cakes) to share information up and down the organizational stack.  This is very good, and getting the mission/business/data/program owners to recognize their responsibilities is an awesome thing.

The Bad:

SP 800-39 is good in philosophy and a general theme of taking ownership of risk by the non-IT “business owners”, when it comes to specifics, it raises more questions than it answers.  For instance, it defines a function known as the Risk Executive.  As practiced today by people who “get stuff done”, the Risk Executive is like a board of the Business Unit owners (possibly as the Authorizing Officials), the CISO, and maybe a Chief Risk Officer or other senior executives.  But without the context and asking around to find out what people are doing to get executive buy-in, the Risk Executive seems fairly non-sequitor.  There are other things like that, but I think the best summary is “Wow, this is great, now how do I take this guidance and execute a plan based on it?”

The Ugly:

I have a pretty simple yardstick for evaluating any kind of standard or guideline: will this be something that my auditor will understand and will it help them help me?  With 800-39, I think that it is written abstractly and that most auditor-folk would have a hard time translating that into something that they could audit for.  This is both a blessing and a curse, and the huge recommendation that I have is that you brief your auditor beforehand on what 800-39 means to them and how you’re going to incorporate the guidance.

• Opportunity Costs and the 20 Critical Security Controls
• 20 Critical Security Controls: What They Did Right and What They Did Wrong
• NIST Cloud Conference Recap
• Ooh, “The Word” is out on S 3474
• Cloud Computing and the Government

With RSA wrapping up, I figured I would do something fun with Alice, Bob, and crypto.  There is a need for small digital signatures (Micro Digital Signatures/”MicroDigiSigs” if I can be as bold as to think I can start a nerdy meme) and tools to support them over small message spaces such as The Twitters, SMS/Text Messaging, barcodes, jabber/xmpp, and probably tons of other things I haven’t even thought of.

Elliptic Curve Cryptography (ECC) provides a solution because of some inherent traits in the algorithms:

• Speed to compute
• Low processor load
• Small keys
• Small signatures

Some general-type info to know before we go further with this:

• OpenSSL 1.00 supports ECC functions.  This is teh awesome, thank you OpenSSL peoples.
• You can check out the OpenSSL HOWTO, I derived a ton of info from this resource http://www.madboa.com/geek/openssl/
• Issues with ECC support in OpenSSL:
  • ECC is poorly documented in OpenSSL.  Pls fix kthanx.
  • Some targets are missing from OpenSSL (ECC Digital Signature Algorithm signatures with SHA-256).

Now on to the step-by-step process.   Feel free to shoot holes in this, I’m sure there are tons of other ways to do things.

Show all the available curves:
rybolov@ryzhe:~$ openssl ecparam -list_curves
secp112r1 : SECG/WTLS curve over a 112 bit prime field
secp112r2 : SECG curve over a 112 bit prime field
secp128r1 : SECG curve over a 128 bit prime field
secp128r2 : SECG curve over a 128 bit prime field
secp160k1 : SECG curve over a 160 bit prime field
secp160r1 : SECG curve over a 160 bit prime field
secp160r2 : SECG/WTLS curve over a 160 bit prime field
secp192k1 : SECG curve over a 192 bit prime field
secp224k1 : SECG curve over a 224 bit prime field
secp224r1 : NIST/SECG curve over a 224 bit prime field
secp256k1 : SECG curve over a 256 bit prime field
secp384r1 : NIST/SECG curve over a 384 bit prime field
secp521r1 : NIST/SECG curve over a 521 bit prime field
prime192v1: NIST/X9.62/SECG curve over a 192 bit prime field
prime192v2: X9.62 curve over a 192 bit prime field
prime192v3: X9.62 curve over a 192 bit prime field
prime239v1: X9.62 curve over a 239 bit prime field
prime239v2: X9.62 curve over a 239 bit prime field
prime239v3: X9.62 curve over a 239 bit prime field
prime256v1: X9.62/SECG curve over a 256 bit prime field
sect113r1 : SECG curve over a 113 bit binary field
sect113r2 : SECG curve over a 113 bit binary field
sect131r1 : SECG/WTLS curve over a 131 bit binary field
sect131r2 : SECG curve over a 131 bit binary field
sect163k1 : NIST/SECG/WTLS curve over a 163 bit binary field
sect163r1 : SECG curve over a 163 bit binary field
sect163r2 : NIST/SECG curve over a 163 bit binary field
sect193r1 : SECG curve over a 193 bit binary field
sect193r2 : SECG curve over a 193 bit binary field
sect233k1 : NIST/SECG/WTLS curve over a 233 bit binary field
sect233r1 : NIST/SECG/WTLS curve over a 233 bit binary field
sect239k1 : SECG curve over a 239 bit binary field
sect283k1 : NIST/SECG curve over a 283 bit binary field
sect283r1 : NIST/SECG curve over a 283 bit binary field
sect409k1 : NIST/SECG curve over a 409 bit binary field
sect409r1 : NIST/SECG curve over a 409 bit binary field
sect571k1 : NIST/SECG curve over a 571 bit binary field
sect571r1 : NIST/SECG curve over a 571 bit binary field
c2pnb163v1: X9.62 curve over a 163 bit binary field
c2pnb163v2: X9.62 curve over a 163 bit binary field
c2pnb163v3: X9.62 curve over a 163 bit binary field
c2pnb176v1: X9.62 curve over a 176 bit binary field
c2tnb191v1: X9.62 curve over a 191 bit binary field
c2tnb191v2: X9.62 curve over a 191 bit binary field
c2tnb191v3: X9.62 curve over a 191 bit binary field
c2pnb208w1: X9.62 curve over a 208 bit binary field
c2tnb239v1: X9.62 curve over a 239 bit binary field
c2tnb239v2: X9.62 curve over a 239 bit binary field
c2tnb239v3: X9.62 curve over a 239 bit binary field
c2pnb272w1: X9.62 curve over a 272 bit binary field
c2pnb304w1: X9.62 curve over a 304 bit binary field
c2tnb359v1: X9.62 curve over a 359 bit binary field
c2pnb368w1: X9.62 curve over a 368 bit binary field
c2tnb431r1: X9.62 curve over a 431 bit binary field
wap-wsg-idm-ecid-wtls1: WTLS curve over a 113 bit binary field
wap-wsg-idm-ecid-wtls3: NIST/SECG/WTLS curve over a 163 bit binary field
wap-wsg-idm-ecid-wtls4: SECG curve over a 113 bit binary field
wap-wsg-idm-ecid-wtls5: X9.62 curve over a 163 bit binary field
wap-wsg-idm-ecid-wtls6: SECG/WTLS curve over a 112 bit prime field
wap-wsg-idm-ecid-wtls7: SECG/WTLS curve over a 160 bit prime field
wap-wsg-idm-ecid-wtls8: WTLS curve over a 112 bit prime field
wap-wsg-idm-ecid-wtls9: WTLS curve over a 160 bit prime field
wap-wsg-idm-ecid-wtls10: NIST/SECG/WTLS curve over a 233 bit binary field
wap-wsg-idm-ecid-wtls11: NIST/SECG/WTLS curve over a 233 bit binary field
wap-wsg-idm-ecid-wtls12: WTLS curvs over a 224 bit prime field
Oakley-EC2N-3:
IPSec/IKE/Oakley curve #3 over a 155 bit binary field.
Not suitable for ECDSA.
Questionable extension field!
Oakley-EC2N-4:
IPSec/IKE/Oakley curve #4 over a 185 bit binary field.
Not suitable for ECDSA.
Questionable extension field!

ECC keys are specific to curves.  Make a key for secp256k1, it’s fairly standard (ie, specified in NIST’s DSA Signature Standard (DSS) as are all of the secp* curves).

rybolov@ryzhe:~$ openssl ecparam -out key.test.pem -name prime256v1 -genkey
rybolov@ryzhe:~$ cat key.test.pem
—–BEGIN EC PARAMETERS—–
BggqhkjOPQMBBw==
—–END EC PARAMETERS—–
—–BEGIN EC PRIVATE KEY—–
MHcCAQEEIGkhtOzaKTpxETF9VNQc7Nu7SMX5/klNvObBbJo/riKsoAoGCCqGSM49
AwEHoUQDQgAEXmD6Hz/c8rxVYe1klFTUVOxxKwT4nLRcOLREQnC5GL+qNayqx7d0
Q+yal6sVSk013EbJr9Ukw/aiQzbrlcU1VA==
—–END EC PRIVATE KEY—–

Make a public key.  This is poorly documented and I had to extrapolate from the RSA key generation process.
rybolov@ryzhe:~$ openssl ec -in key.test.pem -pubout -out key.test.pub
read EC key
writing EC key

rybolov@ryzhe:~$ cat key.test.pub
—–BEGIN PUBLIC KEY—–
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEXmD6Hz/c8rxVYe1klFTUVOxxKwT4
nLRcOLREQnC5GL+qNayqx7d0Q+yal6sVSk013EbJr9Ukw/aiQzbrlcU1VA==
—–END PUBLIC KEY—–

Make a test message:
rybolov@ryzhe:~$ echo “destroy all monsters” > msg.test
rybolov@ryzhe:~$ cat msg.test
destroy all monsters

Generate MD5, SHA-1, and SHA-256 hashes:

rybolov@ryzhe:~$ openssl dgst -md5 msg.test
MD5(msg.test)= a4a5e7ccfda28fdeb43697b6e619ed45
rybolov@ryzhe:~a$ openssl dgst -sha1 msg.test
SHA1(msg.test)= 4d1d1b917377448a66b94e1060e3a4c467bae01c
rybolov@ryzhe:~$ openssl dgst -sha256 msg.test
SHA256(msg.test)= efd54922696e25c7fed4023b116882d38cd1f0e4dcc35e38548eae9947aedd23

Make a signature, note that every time you make a signature with ECC it will be different.
rybolov@ryzhe:~$ cat msg.test | openssl dgst -sha1 -sign key.test.pem -out test.sha1.sig

rybolov@ryzhe:~$ cat msg.test | openssl dgst -sha1 -sign key.test.pem
0E!ÔøΩÔøΩÔøΩEÔøΩ-y
ÔøΩÔøΩ1K2ÔøΩÔøΩ›§{!ÔøΩv4+ÔøΩÔøΩÔøΩÔøΩ WÔøΩ    ÔøΩcÔøΩÔøΩP≈ô—áÔøΩaÔøΩ*~)@aÔøΩ1ÔøΩJ>ÔøΩdÔøΩ

Make the signature readable/text by encoding it with Base64:
rybolov@ryzhe:~$ openssl enc -base64 -in test.sha1.sig
MEUCIGbR7ftdgICMZCGefKfd6waMvOM23DJo3S0adTvNH5tYAiEAuJ6Qumt83ZsL
sxDqJ1JNH7XzUl28M/eYf52ocMZgyrk=

rybolov@ryzhe:~$ wc -m test.sha1.sig.asc
98

rybolov@ryzhe:~$ openssl enc -base64 -in test.sha1.sig > test.sha1.sig.asc

Validate the signature:
rybolov@ryzhe:~$ openssl dgst -sha1 -verify key.test.pub -signature test.sha1.sig msg.test
Verified OK

OpenSSL is dumb here because it can’t read base64:
rybolov@ryzhe:~$ openssl dgst -sha1 -verify key.test.pub -signature test.sha1.sig.asc msg.test
Error Verifying Data
3077905144:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1320:
3077905144:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:382:Type=ECDSA_SIG

So we can use OpenSSL encode with the -d flag to make a binary version:
rybolov@ryzhe:~$ openssl enc -base64 -d -in test.sha1.sig.asc -out test.sha1.sig.bin
rybolov@ryzhe:~$ cat test.sha1.sig.
test.sha1.sig.asc  test.sha1.sig.bin
rybolov@ryzhe:~$ cat test.sha1.sig.bin
0E fÔøΩÔøΩÔøΩ]ÔøΩÔøΩÔøΩd!ÔøΩ|ÔøΩÔøΩÔøΩÔøΩÔøΩÔøΩ6ÔøΩ2hÔøΩ-u;ÔøΩÔøΩX!ÔøΩÔøΩÔøΩÔøΩk|›õ
ÔøΩÔøΩ’RMÔøΩÔøΩR]ÔøΩ3ÔøΩÔøΩÔøΩÔøΩpÔøΩ` π
rybolov@ryzhe:~$ openssl dgst -sha1 -verify key.test.pub -signature test.sha1.sig.bin msg.test
Verified OK

We can also do a prverify which is to verify the signature using the private key:
rybolov@ryzhe:~$ openssl dgst -sha1 -prverify key.test.pem -signature test.sha1.sig.bin msg.test
Verified OK

Now to use this whole thing, you’ll need concatenate the signature with the massage and add a delimiter or send 2 messages, one with the message, the other with the signature.  Any kind of special character like |!^% etc works great as a delimeter, so something like this works:

MEUCIGbR7ftdgICMZCGefKfd6waMvOM23DJo3S0adTvNH5tYAiEAuJ6Qumt83ZsLsxDqJ1JNH7XzUl28M/eYf52ocMZgyrk=destroy all monsters

destroy all monsters|MEUCIGbR7ftdgICMZCGefKfd6waMvOM23DJo3S0adTvNH5tYAiEAuJ6Qumt83ZsLsxDqJ1JNH7XzUl28M/eYf52ocMZgyrk=

Topics for further research:

I haven’t talked at all about key distribution.  This gets real hard real fast just for the simple fact that you have to get an initial key to both ends of the conversation.  You can do key rotation inband, but that first hookup is a logistical effort.  Glad to hear ideas on this.

To get a smaller signature, use MD5 and secp112r1.  Normally you wouldn’t create digital signatures using MD5 (US Government standard is moving to SHA-256), but it’s a tradeoff in paranoia/crackability with signature size.  You have to do each of the steps manually because the objects for ECDSA only use SHA-1:

• Hash the command
• Encrypt the hash using the private key
• Convert the encrypted hash to base64

You can use the OpenSSL shell prompt to save some keystrokes: openssl<enter>  You can also call OpenSSL as a C library, which should work nicely for embedded code.

I’m interested in building a comparison table of the following items, I just haven’t had time to build a script to compare all the data for me:

• ECC Curve
• Time to Compute a Signature
• Size of Signature
• Relative key and signature strength

• FIPS and the Linux Kernel
• QR Code Temporary Tattoos Howto
• Declan McCullagh and Anne Broache on “Will security firms detect police spyware?”
• How to Get a Security Assessment the NIST Way
• When Standards Aren’t Good Enough

• IKANHAZFIZMA Does Awareness Training
• Conflicker ala IKANHAZFIZMA
• Noms and IKANHAZFIZMA
• FedRAMP Released “Real Soon Now”, Lolcats Happy
• Lolcats Coming to you from the Cloud