Tuesday, August 30, 2016

OASIS PKCS11 TC Published PKCS#11 2.40 Errata 01 and Header Files!

After we released PKCS#11 2.40, the PKCS11 Technical Committee and our public reviewers found some issues. I'm proud of the work the technical committee did with the public to create  Errata documents for PKCS#11 2.40.

These documents, where created, supersede PKCS#11 v2.40. That is,  if there is an updated constant identifier in the Errata, that should be considered correct.  The PKCS#11 2.40 Usage Guide remains the most up to date, and it is a committee note (not a standard).

In addition to the updated errata documents, we are excited to launch our first official set of header files since moving under the OASIS banner (aka "normative computer language definition files"): pkcs11.h, pkcs11f.h, and pkcs11t.h.

The PKCS11 TC has published Approved Errata for PKCS #11 V2.40. See the announcement at https://www.oasis-open.org/news/announcements/pkcs-11-v2-40-approved-erratas-published-by-pkcs-11-tc or use the links below.

Wednesday, July 6, 2016

Remembering Roger Faulkner, UNIX Legend

Roger Faulkner, UNIX engineer since 1976, SunOS/Solaris developer since 1990, creator of /procfs, passed away this past weekend.
Photo by Sherry Q. Moore, 2010. 

Roger Faulkner, or raf as his co-workers knew him, was intelligent and had no patience for fools. He was always happy to share history of UNIX, libc, /proc or any other kernel internals, or his opinion on how things should continue to be improved. If you broke the gate in any way shape or form, he'd let you know within a few hours - and if you blocked his project with this breakage, he would not hesitate to let everyone know. He was an amazing colleague with a wry sense of humor and will be missed.   Most folks remember him as that really smart guy that was tough on the outside and sweet, gentle and kind on the inside.  (and seeing that sweet inside wasn't so hard :-)

Roger did not care how senior the engineer (or management) was - he would not let them get away with things that would hurt UNIX or Solaris. He was also always willing to answer questions, do a code review, or help debug an interesting kernel dump. I learned a great deal from him - how to be a good engineer, how to do an excellent root cause analysis, how to know when a bug is really, truly fixed. 

UPDATE July 7, 2016: Obituary is posted here online.  There is a tribute page there as well, where you can leave notes for his family and friends.

UPDATE: July 20, 2016: Roger's Memorial will be livestreamed Saturday 7-23-16, 1p EDT/10a PST/6p BDT.   Streaming will begin 30 mins prior to the memorial service. Youtube channel memorial broadcast:  Memorial Service.

Roger's more extensive bio, courtesy of his manager, Rob Stephens:

Roger grew up in North Carolina and earned a BS in Physics from North Carolina State University in 1963 and a PhD in Physics from Princeton University in 1968. He became involved with UNIX in 1976 when he helped set up and enhance a UNIX service at Bell Labs, Naperville, IL. Roger returned to Bell Labs, Murray Hill, NJ, in 1979 where he continued to work on UNIX development for two years. He moved to New York City in 1981 to do something entirely different for four years, but he couldn't stay away from UNIX. Roger worked at Unix Systems Laboratory 1986-1988 attempting to develop an application debugger for System V Release 3. The result was the first /proc file system for System V and the truss(1) utility for tracing/displaying application-level system calls.

Roger joined Sun Microsystems in 1990 to work on the merge of AT&T's SVr3 and SunOS4.x to create UNIX SVr4 (a.k.a. Solaris 2.0 at Sun). He then concerned himself with the definition, exposure, and maintenance of the Solaris/UNIX process model, with emphasis on visibility into and support for debugging application programs:

From 1990-1993 he extended the ioctl-based /proc interface from being a single-threaded process model to being a multi-threaded process model with lightweight processes within the traditional process.
Photo by Sherry Q. Moore, 2010

In Solaris 2.6 (1995-1996) Roger created the structured /proc file system, with each entry under /proc being a directory rather than a file, each pid directory under /proc containing individual files and other directories reflecting the full process model for both inspection and control. Programming interfaces defined by the proc(4) manual pages.

In Solaris 8 (1997-1998) Roger created the alternate libthread as a better support library for multi-threading. It is a one-to-one thread/lwp interface rather than the old N-to-M thread/lwp interface implemented in the original Solaris libthread. The alternate libthread become the only threading library in Solaris 9.

In Solaris 10 Roger created the unified process model in which all threading support is folded into libc. All processes became multi-threaded, in principle, eliminating the confusion of having three separate process models as was the case previously. Eliminated static linking of the system libraries; all processes are dynamically linked.

Roger then implemented system changes to enable Solaris 11 to conform to the latest POSIX standard (UNIX V7).

[Solaris 12 work redacted, but let it be known, he's done a lot.]

Roger also lent his expertise to countless Solaris projects and was generous with his time and knowledge as he helped many engineers develop their own expertise about all things UNIX. Roger's dry sense of humor, his chuckle, his irreverence for management, his passion for UNIX, and his inspiration will be missed by everyone who had the privilege to work with him.  Please feel free to share this as it is impossible to include everyone Roger worked with over his many years.

I think Sherry Q. Moore really summed him up in her Facebook post:
 What I learned from Roger:
- You can be brilliant and kind.
- "If you don't have time to do it right, when will you have time to do it over?"
- You can be creative and productive for as long as you want.
- "When you are about to do a putback, if your heart is not pounding, palms not sweating, you shouldn't be doing this (be a kernel engineer) any more."
Meem (Peter Memishian) shared the following (Note: the below source comment can be viewed freely online in context):
Indeed.  Today I lost one of my professional heroes.  As those on PSARC
well know, Roger cast a shadow far beyond his truly immense technical
contributions to UNIX (and Solaris in particular).  His curmudgeonly
outwardness belied a remarkably gentle and caring internal character.
Despite having forgotten more about UNIX than most of us could ever know,
he was as grounded as they come, with a unique style that left indelible
memories on so many of us, and altered the DNA of our engineering culture.

Speaking personally, I've always admired those who prioritize doing over
talking.  Roger was one who quietly moved mountains -- as Bryan captured
in the approval of Roger's RTI which put the final nail in the coffin of
the M-to-N threading model:


And of course, Roger wasn't afraid to speak his mind when necessary --
as captured in this gem above cv_wait_stop():

  * Same as cv_wait(), but wakes up (after wakeup_time milliseconds) to check
  * for requests to stop, like cv_wait_sig() but without dealing with signals.
  * This is a horrible kludge.  It is evil.  It is vile.  It is swill.
  * If your code has to call this function then your code is the same.

Finally, I'd like to share this mail from many moons ago on the history of
the name "truss", which embodied the soul that he infused into his work.

 | From: "Roger A. Faulkner" <Roger.Faulkner@Eng>
 | To: meem@Eng
 | Subject: Re: curiosity: truss?
 | Date: Wed, 27 Jan 1999 23:34:47 -0800 (PST)
 | For your edification, this is the geneaology of the name "truss"
 | (taken from some mail dated Sep 26, 1988)
 | This was when Ron Gomes and I were jointly developing the first
 | /proc for SVR4 at USL.
 | -----------------------------------------------------------------
 | We considered, and discarded, several alternative names for truss(1),
 | including "trace", before settling on "truss".  The objection to
 | "trace" is that it's too generic a term and shouldn't be co-opted
 | for a specific use like this; there are lots of other things that
 | one might trace.  Among the alternate names we considered were:
 | "ptrace"  (but this incorrectly implies a connection with ptrace(2)),
 | "strace"  (but this is already used for some streams tracing thing),
 | "tss"     for "trace syscalls and signals" (but this is certainly bad),
 | "sst"     a permutation of "tss" (but this implies it's blinding fast),
 | "trss"    another variation of "tss" (but this is unpronouncable).
 | Adding the obvious vowel gave us "truss", which can be construed
 | to mean "TRace Unix Syscalls and Signals".
 | "truss" seems to have the right combination of mnemonic value
 | and disrespect for authority ("If your program doesn't work, put
 | it in a truss.")  It conjures up a mental image which is fairly
 | accurate, considering what the program does.

Rest in Peace, Roger.  May all your RTIs be promptly approved. 
Tim Foster did an in memoriam integration into the ON gate for Roger. He will live in Solaris forevermore.

Below are some tweets I saw passing by.... Please share your own thoughts below, or send to me and I will share them here.

Do you have any memories of raf? Please share in the comments or in your own space.

We are collecting pictures for his family and friends in the Roger Flickr group. Please add your own there.

Don't worry Roger, someone will approve your RTI.

Thursday, June 30, 2016

Pride: Oracle Santa Clara Campus

I had a big post planned for earlier this month. How I had read in the Mountain View Voice, my town's local paper, that the city council was arguing about whether or not the city should fly the rainbow flag for one day in June.  How silly I thought that was and how proud I was that Oracle, and Sun before, has flown the pride flag annually for the entire month of June.

Then Orlando happened.

I didn't know what to say anymore.

So, here is the picture. 

The flag is still flying today.

No more hate, y'all, okay?  thanks.

Friday, May 20, 2016

ICMC16: Unboxing the White-Box: Practical Attacks Against Obfuscated Ciphers

Jasper van Woudenberg, CTO North America, Riscure

Jasper has been doing white boxing for a long time - hacking assembly in a video game to get passwords for higher levels as a kid :-)

It's important to protect the keys. Is it possible to do it with just software? White-box cryptography -> secure software crypto in an untrusted environment. This is used today in Pay TV DRMs, mobile payments... How to apply this to software environments?

Protection against key extracton in the white-box security model. A technique that allows merging a key into a given crypto algorithm: described for the first time in 2002 by S. Chow, et al. Available for DES and AES. Lookup tables are used for applying mathematical transforms to data. A known weakness is cloning/lifting.

Once you start applying these, you will have a huge amount of lookup tables. Attaks for all academic WBC proposals focus on key extractions, types of transformations assumed known and concrete transformation and key unknown.  In real life, we do not know much about the design. 

You can do an attack on DES using fault injection. There is a challenge online for you to try yourself at whiteboxcrypto.com . 

Then we got a demo of the tool retrieving a DES key by using the fault injection.

Have been able to break all that they've tried with fewer than a 100 faults, except  one that uses output encoding.

If you can perform measurement of the crypto target, you have a good chance of getting the key.

For side channel attacks, no detailed knowledge is required. the only protection is a secret random input/output encoding.

to protect against side channel attacks: must prevent statistical dependence between intermediates and key. Typical countermeasures based on randomness difficult in white-box scenario. 

Make sure you obfuscate control-flow and data, add anti-analysis and anti-tamper countermeasures. 

ICMC16: Cryptography as a Service (CaaS) for Embedded Security Infrastructure

Matt Landrock, CEO, Cryptomathic

 What can we expect from embedded systems?  Internet of Things.... Things: PCs, Phones, Smartmeters,dishwashers, cars, apps.

 Often want to validate code running on the "thing" and enable the thing to carry out basic cryptographic functions.  Understanding that "things" in the IoT can mean pretty much anything security-wise (from high-end to low-end).  if security adds too much inconvenience or cost, it will be skipped or skimped.

HSMs are under-utilized in the IoT space. Crypto APIs tend to be complicated, auditing individual projects is expensive and key management is often over-looked.   

If we think about crypto as a service, then we only have one place to deploy the HSMs, and can get it right. In one deployment, the customer went from securing 3 applications with HSMs to over 180 with this model.

Need to make sure that all applications that need cryptography can receive service, but at the same time only provide service to legitimate users

Cryptomathic has built a crypto service gateway (CSG).  CSG shares HSMs between applications, helping us get away from silos.  this improves utilization of very expensive resources. In this configuration, HSMs can be added and removed, while the service still stays up.

CSG has a crypto firewall that only allows specified commands and by approved card holders, as defined by the security team. The product also focuses on making audit easy. It's in one place and easy to read.

They have created a Crypto query language (CQL), like "DO CODESIGN FROM Dev WITH DATA 01234".  This makes it easier for developers to use, encouraging them to use cryptography.

It is possible here to give crypto keys an expiry.  The CSG provides all key management and handles key usage policy.

Use key labels, so they ar eeasy to find using CQL. They are implicit. 

Overall, there are many more devices coming online and the easier we can make it for developers to do security, the more likely it is to happen.

ICMC16: Entropy As a Service: Unlocking the Full Potential of Cryptography

Apostol Vassilev, Research Lead–STVM, Computer Security Division, NIST

Crypto is going smaller and light weight, lightweight protocols, apis, etc.

In modern cryptography, the algorithms are known. Key generation and management govern the strength of the keys. If this isn't right, the keys are not actually strong.

In 2013, researchers could find keys from a smart card, due to use of low-quality hardware RNG, which was stuck in a short cycle.  Why was this design used? Didn't want to pay for a higher quality piece of hardware or licensing of patents.

Look at the famous "Mining your Ps and Qs: Detection of Widespread Weak Keys in Network Devices", which found that 0.75% of TLS certificates share keys, due to insufficient entropy during key generation.

One of the problems is that there is a lot of demand for entropy when a system boots... when the least amount of entropy is available.

Estimating randomness is hard. Take a well-known irrational number, e.g. Pi, and test the output bit sequence for randomness - it will be reported as random (NIST has verified this is true).

Check out the presentation by Viktor Fischer, Univ Lyon, UJM-Saint-Etienne, Laboratoire, Hubert Curien: NIST DRBG Workshop 2016.

He noted that using the statistical test approach of SP 800-90B makes it hard to automte the estimation of entropy. But automation is critically important for the new CMVP!

The solutions - an entropy service!  NOT a key generation service (would you trust the government on this!?). Not similar to the NIST beacon.

Entropy as a Service (EaaS).   Followed by cool pictures :-)

Key generation still happens locally. You have to be careful how you mix data from a remote entropy server.

While analyzing Linux, they discovered the process scheduling algorithm was collecting 128 bits of entropy every few seconds. Why? Who knows.

EaaS needs to worry about standard attacks on web service and protocol, like message replay, man in the middle an dns poisoning.  But, other attack vectors - like dishonest EaaS instances. You will need to rely on multiple servers.

EaaS servers themselves will have to protect against malicious clients, too.

Project page: http://csrc.nist.gov/projects/eaas

Thursday, May 19, 2016

ICMC16: Entropy Requirements Comparison between FIPS 140-2, Common Criteria and ISO 19790 Standards

 Richard Wang, FIPS Laboratory Manager, Gossamer Security Solutions, Tony Apted, CCTL Technical Director, Leidos

Entropy is a measure of the disorder, randomeness or uncertainty in a closed system.  Entropy underpins cryptography, and if it's bad, things can go wrong.  Entropy sources should have a noise source, post processing and conditioning.

There is a new component in the latest draft of SP 800-90B that is discussing post processing.  there are regular health tests, so any problems can be caught quickly.

There are 3 approved methods for post-processing: Von Neumann's method, Linear filtering method, Length of runs method.

The labs have to justify how they arrived at their entropy estimates. There should be a detailed logical diagram to illustrate all of the components, sources and mechanisms that constitute an entropy source. Also do statistical analysis.

When examining ISO 19790, their clauses on entropy seemed to line up with FIPS 140-2 IG's - so if you meet CMVP requirements, you should be ready for ISO 19790 (for entropy assesment).

Common Criteria has it's own entropy requirements in the protection profiles. The Network Device PP, released in 2010, defined an extensive requirement for RNG and entropy. You have to have a hardware based noise source, minimum 128 bits of entropy and 256 bits of equivalent strength.

The update in 2012 allowed software and/or hardware entropy sources. It was derived from SP 800-90B, so very similar requirements.

Entropy documentation has to be reviewed and approved before the evaluation can formally commence.

Some vendors are having trouble documenting thrid party sources, especially hardware.  Lots of misuse of Intel's RDRAND.