Wave Systems Corp. (fka WAVXQ)

[brant_point]

Why is NIST Standing Against Common Sense and Solid Science?

Imagine embedded sensors distributed throughout networks to serve as (pardon this inexact analogy) plane-spotters. Or envision a cyber security ecosystem with endpoints that automatically share information about the status of their “health.”

Admittedly, neither of these ideas is visionary. In fact, I want to make it plain… I’m not aiming for anything visionary. I want something practical.

And each scenario depends on there being a way to “root” assertions and information in hardware, thereby ensuring a level of integrity that software alone cannot achieve. And, obviously, it would be better if such a hardware root were based in standards… that would enable interoperability.

(Over 30 years of research confirms a critical concept: Software cannot protect software. In a 1979 paper about Trusted Computing Base or TCB architectures, a MITRE researcher noted that, “…. In future computer architectures, more of the TCB functions may be implemented in hardware or firmware.” And, now, as I will explain in a moment, such TCB functionality has indeed been implemented in hardware. (SOURCE): http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA108831 )

In over 600 million PCs, such a hardware root of trust exists. Today. It’s called the “Trusted Platform Module” (or TPM.) It’s based on the open standards created by the non-profit Trusted Computing Group (see http://www.trustedcomputinggroup.org for details.)

While the use of TPMs (and their mobile equivalent) has been repeatedly recommended by our NSA, the premier cryptology research organization in the world, UK’s CESG, and is viewed as integral by Microsoft for Windows 8 and upcoming mobile phones, there is one organization that can’t seem to make up its mind about this critical, standards-based root of trust:

I’m speaking of the National Institute of Standards and Technology (NIST.)

On the one hand, NIST has repeatedly cited the TPM as the prime (and sometimes the only) example of the kind of hardware root of trust that its researchers believe is necessary to create a fixed reference point against which one can measure change.

On the other hand, NIST has yet to certify TPMs via FIPS 140-2.

TPMs are being used in some of our country’s most sensitive environments, e.g. Special Operations. Apparently, this is the result of NIST issuing some kind of waiver for National Security Systems.

But, as I understand it, TPMs can’t be used by DHS… or anywhere outside of the DoD… because they lack FIPS 140-2 certification.

Will you join me in informing NIST that a decade’s worth of open standards work hangs in the balance… and that it is time for them to stand up for standards?

Thank you for any support you can provide. Or, at the very least, thank you for keeping an open mind with regards to this important topic.

10 hours ago
.
Like
Comment
Follow
Flag


More




William (Bill) Norvell likes this


.
1 comment


Follow Steven


Steven Sprague • I could make a very strong argument that TPM should have i's own category.

While we have failed to get NIST to pay enough attention to establishing FIPS or a waiver the government requires TPM for Protecting bitlocker keys but then some are confused if it can protect Microsoft Crypto API keys like wireless and VPN and continue to use the windows registry. This includes the DISA Non Person Entity program that consistently has stood behind the IT's NOT FIPS so we don't have to do it correctly. I stopped pushing that group 2 years ago and they still have to make any progress. The problem will be NIST 800-147 and NIST 800-155. A TPM reports the signatures of the log files on a device. This means that the log files are not compromised. The question is what is written in the log. This will ultimately require some form of certification of the LOG Creation process and some type of gold master for the integrity measurements. This will ultimately necessitate a certification process in the supply chain. This needs leadership and this needs a stronger market.
Surprise Surprise we discovered this week that USB Smartcard Readers could have the pin code captured and the card remoted. https://www.computerworld.com/s/article/9233697/Proof_of_concept_malware_can_share_USB_smart_card_readers_with_attackers_over_Internet
Broadcom Universal Security Hub is in most dell PCs and was in all dell PCs provided the Smartcard Interface, the Keyboard Interface, NFC and the TPM all on a single CHIP. Efforts to put the keyboard in to a secure mode during PIN entry were deemed to have no market demand. For the record Wave would have invested in building the software. But the chip needed a few tweaks that never happened. The biometric PIN release is calculated on CHIP

My point is this stuff is not NIST 140 that defines encryption and authentication key storage, not secure systems.

FIPS 201 defines the PIV protocols but left PIN entry non secure.

It is time for a trusted computing special publication that covers

Machine held authentication tokens TPM and similar
Device level ID (no user interaction required)
Proven Device attributes or capabilities this is the 800-147 800-155 stuff
User to device Binding (SED drive user access, PIN number user access, Biometrics (facial, finger, voice, retina scan)
As we have to trust devices more and more there needs to be more of a specification. There is no category “mobile” these are all just devices that are outside of a physical control environment. I agree NIST has not embraced TPM as a category in the correct way yet and it hampers the adoption and as a result we continue to use unknown devices that are killing the tamper resistance of our infrastructure.

Steven Sprague

15 minutes ago •
http://www.linkedin.com/groupItem?view=&gid=113049&type=member&item=187569832&commentID=105335692#commentID_105335692