It looks like the article on the XTS mode of AES finally made its way into Cryptologia. If you don't subscribe to Cryptologia, you can get a copy of the article here, although you'll have to pay either $58 for the entire issue that it's in or $43 for the single article. Either price seems a bit high to me.
New innovation and emerging technology brings with it opportunities for streamlining costs, eliminating hurdles for end users and reducing risks to the business. However, implementing game changing solutions can be unique to your environment, policies and processes.
That's why I invite you to join Voltage Security at its first customer summit in New York City on November 9, 2011. The summit will focus on data-centric security and will feature top Voltage customers such as Amex, Wells Fargo, State Street and others, who will discuss how they implemented encryption projects for mail, data and payments. Also presenting will be Eric Ouellet, research vice president with Gartner Group, who is currently developing new analyses of how companies use encryption. The summit features customers talking to customers—at last count this includesAmerican Express, BJ's Wholesale Club, Citigroup, Deutsche Bank, Fidelity Investments, JPMorgan Chase, UBS, State Street Bank andWells Fargo. The goal of the summit is to enable Voltage customers to network with each other and pick up valuable best practices. If you're interested in attending, please visit www.voltage.com/live.
The theme is 'Data-centric Security for a Data-centric World,' it's an area of huge attention. Data is the lifeblood of industry, commerce and leisure, every business and every transaction. That's why protecting it is such a serious and difficult responsibility.
Here's a quick scan of the Hot Topics we have on tap at Voltage Security Live 2011:
|
|
There's no question that every company continues to face a long serious of challenges related to these topics. The conference is designed to tackle specific issues and help formulate achievable solutions. The areas to be covered include:
Voltage Security Live 2011 will bring together the brightest minds in our field, all with considerable experience. There will be representatives from teams responsible for implementation, as well as enterprise and security architects looking for, and developing, best practices for data-centric encryption.
The sessions will cover customer project case studies addressing issues such as how to maximize end-user adoption for your B2C implementations and implementing data-centric encryption projects, while the Customer Track focuses on panel discussions and presentations on topics such as protecting outsourced data, eDiscovery and Archiving and securing application emails. There's also an Architecture Track, featuring panel discussions and presentations on topics such as key management architecture, security policy, enterprise applications and the web services API and scalable design considerations. And there's the Security Panel, with a discussion and general Q&A featuring leaders from the security community—Gartner Security Analyst, Encryption Architects, QSAs.
There's going to be a broad cross-section of security specialists attending, but some executives will find it particularly enlightening: CXOs and security leaders responsible for security strategy and programs; VPs/Directors responsible for security implementation; and architects responsible for security and application and enterprise architecture. If you have one of these roles, we think this conference is exactly right for you.
We know there are constant demands on your time - we hope to see you there.
Register at www.voltage.com/live
According to a post on Josh Brickman's blog, from what we say at the most recent International Common Criteria Confererence, it looks like countries are starting to weasel out of their commitments to recognize Common Criteria certifications. There are supposed to be exceptions to the recognition of CC certifications, but as far as I can tell, the exceptions are supposed to be limited to classified information. Here's what Article 3 (Exceptions) of the CCRA Agreement (PDF) say about this:
If to recognise a Common Criteria certificate would cause a Participant to act in a manner inconsistent with applicable national, international or European Community law or regulation, that Participant may decline to recognise such a certificate. In particular, in cases where an IT product or a protection profile is being considered for an application which involves the protection of information attracting a security classification or equivalent protective marking required or authorised under the provisions of national law, subsidiary legislation, administrative regulation or official obligation, Participants may decline, in respect of that application only, to recognise a certificate.
The way that countries are trying to avoid really making CC certifications common seems to be requiring that certifications that they recognize are only against protection profiles that they recognize (i.e., write themselves). From my reading of the CCRA Agreement, that's actually not a valid approach. Here's Article 2 (Scope) of the CCRA that leads me to believe this:
It is mutually understood that, in respect of IT products and protection profiles, the Participants plan to recognise the Common Criteria certificates which have been authorised by any other certificate authorising Participant in accordance with the terms of this Arrangement and in accordance with the applicable laws and regulations of each Participant. This Arrangement covers claims of compliance against any of the Common Criteria assurance components required for Evaluation Assurance Levels 1 through 4. Extension of the scope may be agreed by the Participants in this Arrangement at any time, in accordance with the provisions of Article 14, by adding other assurance levels or components.
I don't see how the approach that Brinkman sees countries trying is consistent with that.
The Common Criteria doesn't really give a very useful evaluation from the security point of view. Its big benefit is that lots of countries recognize it. So instead of getting several expensive and meaningless certifications done (one for each country whose government you're trying to sell to), you only need to get one expensive and meaningless certification done. This makes life much easier for vendors. It also saves governments money because they don't end up absorbing the additional costs that getting lots of different certifications causes. The approach that countries seem to want to try seems to make like easier for neither vendors nor national governments. Vendors will get stuck doing multiple CC evaluations and they'll pass the costs of these evaluations on to their government customers who will then end up paying for for evaluated products.
The governments who are trying to essentially eliminate the value of getting a CC certification should really think about the implications of what they're trying to do. What they're proposing won't actually benefit anyone.
Peter Gutmann's book Engineering Security (PDF) is one of the best single books that I've found on the topic of information security. It collects all sorts of information that's both useful and interesting, and it seems to be the only place where this type of information is collected. If you read a chapter of this book, you're able to amaze and astound people with the fascinating information security knowledge that you have.
My memory's not as good as it used to be, so for me, this effect wears off after a couple of weeks. But for those couple of weeks, I look much smarter than I really am.
I don't know if this book has found a publisher yet, but it's definitely the sort of book that deserves to be printed.
X.509-based PKI has a reputation for being bad in many ways - expensive, hard to use, too complicated, etc.
But is it really that complicated?
To find out, I looked at the number of RFCs that the IETF's PKIX working group has published to date. Then I made the mistake of making a table of them. That took quite a while. There are actually 62 of them, which certainly seems like enough documents to make the technology qualify as "complicated."
Here's what's been written so far:
Document |
Title |
RFC 2459 |
Internet X.509 Public Key Infrastructure Certificate and CRL Profile |
RFC 2510 |
Internet X.509 Public Key Infrastructure Certificate Management Protocols |
RFC 2511 |
Internet X.509 Certificate Request Message Format |
RFC 2527 |
Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework |
RFC 2528 |
Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates |
RFC 2559 |
Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2 |
RFC 2560 |
X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP |
RFC 2585 |
Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP |
RFC 2587 |
Internet X.509 Public Key Infrastructure LDAPv2 Schema |
RFC 2797 |
Certificate Management Messages over CMS |
RFC 2875 |
Diffie-Hellman Proof-of-Possession Algorithms |
RFC 3029 |
Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols |
RFC 3039 |
Internet X.509 Public Key Infrastructure Qualified Certificates Profile |
RFC 3161 |
Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) |
RFC 3279 |
Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile |
RFC 3280 |
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile |
RFC 3281 |
An Internet Attribute Certificate Profile for Authorization |
RFC 3379 |
Delegated Path Validation and Delegated Path Discovery Protocol Requirements |
RFC 3628 |
Policy Requirements for Time-Stamping Authorities (TSAs) |
RFC 3647 |
Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework |
RFC 3709 |
Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates |
RFC 3739 |
Internet X.509 Public Key Infrastructure: Qualified Certificates Profile |
RFC 3770 |
Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN) |
RFC 3779 |
X.509 Extensions for IP Addresses and AS Identifiers |
RFC 3820 |
Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile |
RFC 3874 |
A 224-bit One-way Hash Function: SHA-224 |
RFC 4043 |
Internet X.509 Public Key Infrastructure Permanent Identifier |
RFC 4055 |
Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile |
RFC 4059 |
Internet X.509 Public Key Infrastructure Warranty Certificate Extension |
RFC 4158 |
Internet X.509 Public Key Infrastructure: Certification Path Building |
RFC 4210 |
Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP) |
RFC 4211 |
Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) |
RFC 4325 |
Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension |
RFC 4334 |
Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN) |
RFC 4386 |
Internet X.509 Public Key Infrastructure Repository Locator Service |
RFC 4387 |
Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP |
RFC 4476 |
Attribute Certificate (AC) Policies Extension |
RFC 4491 |
Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile |
RFC 4630 |
Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile |
RFC 4683 |
Internet X.509 Public Key Infrastructure Subject Identification Method (SIM) |
RFC 4985 |
Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name |
RFC 5019 |
The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments |
RFC 5055 |
Server-Based Certificate Validation Protocol (SCVP) |
RFC 5272 |
Certificate Management over CMS (CMC) |
RFC 5273 |
Certificate Management over CMS (CMC): Transport Protocols |
RFC 5274 |
Certificate Management Messages over CMS (CMC): Compliance Requirements |
RFC 5280 |
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile |
RFC 5480 |
Elliptic Curve Cryptography Subject Public Key Information |
RFC 5636 |
Traceable Anonymous Certificate |
RFC 5697 |
Other Certificates Extension |
RFC 5755 |
An Internet Attribute Certificate Profile for Authorization |
RFC 5756 |
Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters |
RFC 5758 |
Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA |
RFC 5816 |
ESSCertIDv2 Update for RFC 3161 |
RFC 5877 |
The application/pkix-attr-cert Media Type for Attribute Certificates |
RFC 5912 |
New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX) |
RFC 5913 |
Clearance Attribute and Authority Clearance Constraints Certificate Extension |
RFC 5914 |
Trust Anchor Format |
RFC 5934 |
Trust Anchor Management Protocol (TAMP) |
RFC 6024 |
Trust Anchor Management Requirements |
RFC 6025 |
ASN.1 Translation |
RFC 6170 |
Internet X.509 Public Key Infrastructure -- Certificate Image |
I just came across an interesting application that's available for Android devices. This particular app let's you create and read encrypted QR (quick response) codes.
QR codes are those images that you see that look something like this:
These were created by Toyota back in 1994 to help track vehicles while they were begin manufactured, but now they're widely used in cell phones and other portable devices. Just take a picture of the QR code and many portable devices can easily translate that picture into a URL, phone number, or whatever was encoded in it. If you're really interested in how these work, you can find out in ISO/IEC 18004:2006 ("Information technology -- Automatic identification and data capture techniques -- QR Code 2005 bar code symbology specification").
The good thing about QR codes is that they're a standard, so anyone with a standards-compliant device can read one. But that also means that there's no privacy for information in QR codes because anyone with a standard-compliant device can read one. One workaround for this is to encrypt the data in a QR code, and that's just what QR Droid lets you do. It uses password-based encryption, so a typical use might be to encrypt those potentially-compromising pictures that you post on Facebook and to only share the password with your friends, thereby keeping any nosy HR people from blackballing you from future jobs because of what you did on your vacation to Cozumel.
Password-based encryption isn't very secure, of course, but it might be secure enough to protect the privacy of what you post on Facebook. If that's what you need, then QR Droid might be just what you're looking for.
Just in case you missed Peter Gutmann's talk "PKI: Lemon Markets and Lemonade" at the 2011 RSA Conference, the slides from his talk are now available (PDF) on his web site.
This talk had some interesting things to say about some of the problems that PKI faced in its early years and how the that vendors dealt with these problems led to disaster. It's easy to reconstruct the talk from just the slides, and there's lots of interesting material in them.
Because it was so much fun to create a visualization of the Common Criteria last week, I decided to try the same thing with FIPS 140-2, the US government's Security Requirements for Cryptographic Modules. Here's what I got. It's clearly a very focused document, isn't it?
An alert reader pointed out that I did something unexpected when comparing NIST's Special Publication 800-153 (PDF), "Guidelines for Securing Wireless Local Area Networks (WLANs) (Draft);" and ANS X9.112, "Wireless Management and Security - Part 1: General Requirements" in a previous post: I didn't include word clouds of each of the standards. To correct that oversight, here they are.
Here's one for SP 800-153:
and here's one for X9.112:
There have been two standards for wireless security that have been released recently. One is NIST's Special Publication 800-153 (PDF), "Guidelines for Securing Wireless Local Area Networks (WLANs) (Draft);" the other is ANS X9.112, "Wireless Management and Security - Part 1: General Requirements." One obvious difference between these standards is their length: SP 800-152 is 24 pages long while X9.112 has 71 pages. As you might expect from that, there's quite a difference in the level of detail that each standard addresses. One easy way to understand the difference in the detail that each document provides is to look at their tables of contents.
Here's the table of contents of SP 800-153:
Executive Summary
1. Introduction
1.1 Authority
1.2 Purpose and Scope
1.3 Audience
1.4 Document Structure
2. WLAN Security Configuration
2.1 Configuration Design
2.1.1 Needs Gathering
2.1.2 WLAN Architecture
2.2 Configuration Implementation, Evaluation, and Maintenance
3. WLAN Security Monitoring
3.1 WLAN Security Monitoring Basics
3.1.1 Attack Monitoring
3.1.2 Vulnerability Monitoring
3.2 Monitoring Tools
3.3 Continuous Monitoring Recommendations
3.4 Periodic Assessment Recommendations
List of Appendices
Appendix A— Supporting NIST SP 800-53 Security Controls and Publications
Appendix B— Acronyms and Abbreviations
Appendix C— References
List of Figures
Figure 1: Simplified View of WLAN Architecture
And here's the table of contents for X9.112:
Foreword
Introduction
1 Scope
1.1 Audience
1.2 Business Case
2 Normative references
3 Terms and definitions
4 Abbreviated terms
5 Wireless Risks
5.1 Introduction
5.2 Applicable Risks
5.2.1 Physical Topology
5.2.2 Access Control - Least Privilege
5.2.3 Encryption
5.2.4 Network Integrity
5.2.5 Wireless Transmission
5.2.6 Unauthorized Wireless Access Devices
5.2.7 Denial of Service (DoS)
5.2.8 Data Integrity
6 Requirements
6.1 Overview
6.2 Wireless Security Policy
6.3 Data Security
6.4 Entity Authentication
6.5 Data Integrity
6.6 Security Encapsulation
6.7 Key Management
6.8 Wireless Networks
6.9 Audit Logging
6.10 Physical Security
6.11 Access Control
7 Wireless Security Policy
7.1 Roles and Responsibilities
7.2 Security Controls
7.3 Technology Controls
7.4 Access Controls
7.5 Configuration Controls
7.6 Cryptography Controls
7.7 Physical Controls
7.8 Log Management
Annex A (normative) Wireless Validation Control Objectives
A.1 Introduction
A.2 Environmental Controls
A.2.1 Security Policy
A.2.2 Security Organization
A.2.3 Asset Classification and Management
A.2.4 Personnel Security
A.2.5 Physical and Environmental Security
A.2.6 Operations Management
A.2.7 System Access Management
A.2.8 Systems Development and Maintenance
A.2.9 Wireless Access Continuity Management
A.2.10 Monitoring and Compliance
A.2.11 Event Journaling
A.3 Key Management Life Cycle Controls
A.3.1 Key Generation
A.3.2 Key Storage, Backup and Recovery
A.3.3 Key Distribution
A.3.4 Key Usage
A.3.5 Key Destruction and Archival
A.3.6 Cryptographic Device Life Cycle Controls
A.4 Wireless Management Life Cycle Controls
A.4.1 Wireless Device Life Cycle
A.4.2 Wireless Encryption
A.4.3 Wireless Authentication
A.4.4 Wireless Integrity
A.4.5 Wireless Encapsulation
Annex B (Normative) Wireless Cryptography Controls
Annex C (Informative) Wireless Technology Standards
Wireless Local Area Networks
C.1 Broadband Wireless
C.2 Bluetooth
C.2.1 Architecture
C.2.2 Client ID
C.2.3 Client Provisioning
C.2.4 External Functional Interface (EFI)
C.2.5 General formats
C.2.6 Multimedia Messaging Service (MMS)
C.2.7 Persistence
C.2.8 Pictogram
C.2.9 Push
C.2.10 Synchronisation
C.2.11 User Agent Profile (UAProf)
C.2.12 Wireless Application Environment
C.2.13 Wireless Protocols
C.2.14 Wireless Security
C.2.15 Wireless Telephony Application (WTA)
C.3 Voice and Messaging
Annex D (Informative) X9 Registry
Annex E (Informative) OCC Risk Management of Wireless Networks
So if you're looking for general guidance and pointers to what other government standards might apply to the security of your wireless networks, SP 800-153 might be what you're looking for. If you're looking for more detailed guidance on how to understand the security of your wireless network and how to improve it, X9.112 might be better for you. On the other hand, SP 800-153 is free while X9.112 costs $100.
It's fairly well known that counterfeit software is a serious problem in some parts of the world. I've seen estimates that say that over 90 percent of software is unlicensed in some countries. But it seems that counterfeit hardware is also a problem, although not as big a problem as counterfeit software. Some estimates say that up to 5 percent of electronic components are counterfeit, which is a much smaller fraction than we see with software.
But it turns out that counterfeit hardware is a big enough problem that there's a standard that tells companies how to deal with it. This is the SAE Aerospace AS5553 Standard - Counterfeit Electronic Parts; Avoidance, Detection, Mitigation, and Disposition.
According to other reports, like the US government's Defense Industrial Base Assessment: Counterfeit Electronics (PDF), the biggest sources of counterfeit parts are China, Taiwan, Phillipines, Malaysia, India, Russia, Indonesia, Vietnam and South Korea, with China being by far the single biggest source of them.
And unlike counterfeit software, which is often virtually identical to the licensed version, it seems that counterfeit electronics are often much lower quality that their legitimate counterparts, so counterfeit parts are most commonly discovered because they're defective. And this also seems to be the main reason that there's a standard that tells how to deal with them.
And because the number of counterfeit electronic components seems to increasing very quickly, we should expect to hear more about this in the future.
Since it's so much fun to run data visualiaztion applications on random stuff, I thought that I'd see what happens when I made a word cloud visualization of the Common Criteria using Wordle. Here's one version of it. Just looking at it gives me unsettling flashbacks to when we did an EAL2 evaluation of SecureMail a while ago.
Over the past 10 years, IBE has become the one of the fastest deployed encryption technologies as measured by the commercial adoption of Voltage SecureMail™ and the use of IBE as a general purpose key management solution used across the Voltage Security product line. Since its commercial launch 8 years ago, Voltage SecureMail has become one of the most widely adopted secure email products in the world with over one billion secure business emails sent annually and over 50 million worldwide users; those numbers are expected to double by 2014.
IBE was first introduced on Tuesday August 21 at the 2001 Crypto conference in a seminal paper by Dan Boneh, Stanford University, and Matt Franklin, University of California Davis. The paper, entitled “Identity-Based Encryption from the Weil Pairing,” set forth a simple but powerful approach for encrypting information with identity-based keys. This cryptography breakthrough became the founding technology for Voltage Security that was incorporated in 2002 by three Stanford students working with Professor Boneh: Matt Pauker, Rishi Kacker and Guido Appenzeller. In July 2003, the new company launched Voltage SecureMail, an email encryption product using IBE to secure messages without the difficulties and expenses of traditional certificates.
Key metrics in the 10 year history of IBE:
World’s Biggest Companies Standardize on Voltage SecureMail
Nearly 30% of the world’s 20 biggest public companies (as listed by Forbes Global 2000) have standardized on Voltage SecureMail powered by IBE including four of the world’s largest global financial institutions; one of the world’s largest retailers, one of the largest U.S. managed healthcare providers and several large regional healthcare providers.
Notable Voltage SecureMail customers from the last year include:
In addition, over 1000 enterprise companies have standardized on Voltage SecureMail, and thousands of mid-size to smaller business use the cloud-based Voltage SecureMail Cloud™ solution to protect private and confidential information.
More information at www.voltage.com
An alert reader recently pointed out that there's a Unicode character that might be particularly suitable for use in describing some of the less-than-accurate data and questionable research that plagues the information security industry. This is the U+1F4A9 code point.
I don't know anyone who's involved in developing Unicode standards so I can't say for sure whether or not that was why U+1F4A9 was included in Unicode 6.0.0, but it's the best reason that I've heard so far.
What's on the NIST web site seems to say everything that needs to be said:
On June 9, 2011, NIST announced a period of public comment on a proposal to approve two schemes of the FFX framework for format preserving encryption: FFX[radix] and VAES3. The public comments that NIST received in response to this request are collected here.
Oddly enough, the comments are all very positive. In situations like these you usually get negative comments by vendors who don't have an interest in the technology which give either weak or obscure technical reasons why a particular proposal is bad.
In a previous post, I introduced FIPS certification and PRNGs. I pointed out that there's a new algorithm (800-90, now called DRBG for Deterministic Random Bit Generator) to be certified. In this post I'm going to talk about that algorithm and how to get it FIPS certified.
One of the twists in the 800-90 standard, is that it requires the implementation to come up with seed material. That is, most old PRNGs worked the same way:
800-90 works this way:
Here at Voltage, we use the term autoseed. That means the PRNG/DRBG seeds itself.
So NIST is requiring that products up for FIPS certification must supply a DRBG that autoseeds. But that brings up the question, how can one test an implementation? With 186-2, it was possible to come up with seed/expected output pairs. But with 800-90, there's autoseeding. We can't guarantee what any seed will be in advance. Furthermore, if we enter a seed, we won't get the expected output because the autoseed will be different every time we run the test.
The answer is to require the implementation to turn off autoseeding in order to run the test. Then, the test supplies some data that is a substitute for the autoseed material, and possibly some more material that is a aubstitute for user-supplied seed. The implementation then generates random bytes and it is compared to an expected value.
This makes sense on one level. In order to test an implementation (make sure they follow the standard), make sure it produces expected output from a specific seed.
However, this also means introduing a security hole.
In order to get FIPS certification, an implementation must turn off autoseeding. But if a user somehow accidentally uses the PRNG/DRBG in FIPS testing mode, and they don't add their own seed, they'll get bad random output. After all, they're using a PRNG/DRBG that seeds itself, so why enter any new seed?
You might declare, "Then don't release the FIPS testing mode version of the PRNG/DRBG." However, one FIPS requirement is that the code tested is the code released. Furthermore, in order to get FIPS certification, it is necessary to perform these "Known Answer Tests" (KATs) at startup. When the user first launches the product, it must run some KATs to show that it is running properly.
It all means that in order to get FIPS certification, we must release the product with FIPS testing mode in there.
We've written our code in such a way that the FIPS testing mode is not publicly available. There are also some hoops to go through to get to that code. So the probability is extremely low -- virtually zero -- that a user will accidentally instantiate in FIPS testing mode. With some research, a user could figure out how to explicitly (as opposed to accidentally) instantiate in that mode, but why would they? So I'm not too worried.
Nonetheless, I don't like this requirement from NIST. I think that NIST should either not require the KAT, or allow an implementation to take out the FIPS testing mode before releasing.
By the way, I can think of one reason someone might make the effor to instantiate in FIPS testing mode, and that is to intentially create a security hole. Someone writing an app that they want to break themselves would appreciate this implementation. Of course, someone wanting to do this would have many, many more ways of inserting back doors. So taking away this code would not thwart them. But no one wants to add anything to help the attackers.
What I really want to talk about is an issue with getting FIPS certification with the new NIST 800-90 DRBG. However, before I get to that, I want to make sure anyone reading these posts know some background.
The internals of a PRNG have two main components: what it does with seed material and how it produces the actual random bytes. If someone invents a PRNG, they specify the operations on the seed material and the operations to perform when actual random bytes are requested.
Most PRNGs use a message digest (cryptographic hash) or block cipher algorithm to convert seed into random bytes. Furthermore, there are specific steps in a specific order to take when performing the operations. You might think, "What's the big deal? Just digest the seed and there's your output." Except a PRNG might need to generate more than one block of data. That is, suppose you use SHA-512 to digest the seed, you get 64 bytes of output. But suppose you need 256 bytes or more? What then? "Just digest the previous output to get the next output?" No, because then anyone looking at some output will know what the next output will be ("I see that with me, the SSL server used an RC4 key of 0x38 C2..., so I know with the next connection, they will use 0x7A 05...").
For that reason, and many more, building a PRNG is not trivial. And once a PRNG exists, and the crypto community studies it and finds it to be good, anyone implementing it should make sure they've implemented it correctly. "Yeah, I've implemented a PRNG algorithm pretty much as defined, but if it's not exact, so what?" Did you introduce a security flaw? Maybe not, but without study, how do you know for sure? The best thing to do is to implement an algorithm exactly as specified so you know you have not introduced flaws. And how do you know you've implemented it correctly? The best test is to make sure you produce expected output given a particular seed.
Back to the 186-2 algorithm. Over the years, several people found some issues with the this PRNG (I'm proud to say I was one of those people: I showed an example of two seeds producing the same output, and that to solve that problem an app should digest all seed material). Hence, NIST decided to develop a new algorithm
NIST recenly came out with that new algorithm and published it in NIST Special Publication 800-90. In that doc, they call the algorithm a "Deterministic Random Bit Generator" or DRBG. In fact, NIST now uses that term for the entire class of algorithms that produce random bytes from a seed.
I'd just like to say that I don't like this new term DRBG. The industry has been using the term PRNG for many years, why come up with a new one? And besides, isn't "Deterministic Random" an oxymoron?
Nonetheless, there's a new algorithm to get FIPS certified. In fact, NIST has said that in the future, the old 186-2 algorithm will no longer be certifiable. In the future, a product up for certification will have to implement 800-90.
Part 2 will talk about this new algorithm and FIPS certification.
What exactly is cloud computing? Until recently, there was some debate of that, but NIST's definition that appears in their SP 800-145, "The NIST Definition of Cloud Computing" now seems to be the definitive one, even if some vendors don't agree with it. Here's their list of the essential characteristics of cloud computing:
On-demand self-service. A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service’s provider.
Broad network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).
Resource pooling. The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, network bandwidth, and virtual machines.
Rapid elasticity. Capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out, and rapidly released to quickly scale in. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be purchased in any quantity at any time.
Measured Service. Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.
Note that virtualization is not part of this definition. And although implementations of cloud computing often use virtualization, it's certainly possible to have implementations of cloud computing that don't use it. You often see vendors of virtualization technologies saying that their technology is an essential part of cloud computing, but while their technologies may be very useful in some particular implementations of cloud computing, they're certainly not an essential feature of it.
NIST has a new draft of their SP 800-63-1, "Electronic Authentication Guideline," available for public comments. This document discusses multi-factor authentication, and it's probably worth sending them comments on this particular topic.
As I mentioned in a recent post, the reason that the judge ruled the way he did in Patco Construction v. People’s United Bank seemed to focus on the FFIEC’s "Authentication in an Internet Banking Environment" (PDF), and this guidance didn’t explicitly say that in multifactor authentication you need to have success with each of the factors for the overall authentication to be a success.
SP 800-63-1 seems to also overlook a clear discussion of this, so if you feel strongly about this, you now have a chance to submit comments to NIST that reflect your thoughts on it. You can find the form for submitting comments here.
SP 800-63-1 also has an interesting discussion of password strength. It uses Shannon entropy instead of minimum entropy to estimate this, and it has a set of guidelines for estimating how many bits of entropy a user-selected password will give you. Here are the guidelines that it has for this:
The following graph summarizes what this gives you for a reasonable range of password lengths.
That's definitely the most thorough analysis of password strength that I've seen in a standard. It may not be perfectly accurate, but then it says that these values
should not be taken as accurate estimates of absolute entropy, but they do provide a rough relative estimate of the likely entropy of user chosen passwords, and some basis for setting a standard for password strength.
What's missing form this analysis, however, is a clear recommendation on exactly how many bits of estimated entropy a password should actually have. Maybe that's also worth commenting on.
The recent DNSSEC workshop in Singapore got some interesting coverage in the San Jose Mercury News:
The Singapore event included an elaborate technical ceremony to create and then securely store numerical keys that will be kept in three hardened data centers there, in San Jose, Zurich and Singapore. The keys and data centers are working parts of a technology known as Secure DNS, or DNSSEC. DNS refers to the Domain Name System, which is a directory that connects names to numerical Internet addresses. Preliminary work on the security system had been going on for more than a year, but this was the first time the system went into operation, even though it is not quite complete.
The three centers are fortresses made up of five layers of physical, electronic and cryptographic security, making it virtually impossible to tamper with the system. Four layers are active now. The fifth, a physical barrier, is being built inside the data center.
As the recent compromises of RAs at Comodo showed us, the weak link in PKI is almost never the CA itself, and a clever hacker will always go after one of the weaker links instead of trying to get the CA's private keys. And it certainly looks like the fortresses that are being built in San Jose, Zurich and Singapore are really designed to keep hackers away from those very keys.
So if a hacker wants to compromise DNSSEC, they almost certainly won't try to beat the security of one of the fortresses. They'll do something much easier like compromising an RA. That means that all of the expensive layers of security around the DNSSEC root keys are probably just for show. They may make people feel better about the security of DNSSEC, but they probably don't really add much actual security because they're designed to defeat attacks that never happen. And these attacks still wouldn't happen if the security measures around the keys weren't as tight.
The PCI Security Standards Council just released their Information Supplement: PCI DSS Virtualization Guidelines (PDF). This document describes how
There are four simple principles associated with the use of virtualization in cardholder data environments:
a. If virtualization technologies are used in a cardholder data environment, PCI DSS requirements apply to those virtualization technologies.
b. Virtualization technology introduces new risks that may not be relevant to other technologies, and that must be assessed when adopting virtualization in cardholder data environments.
c. Implementations of virtual technologies can vary greatly, and entities will need to perform a thorough discovery to identify and document the unique characteristics of their particular virtualized implementation, including all interactions with payment transaction processes and payment card data.
d. There is no one-size-fits-all method or solution to configure virtualized environments to meet PCI DSS requirements. Specific controls and procedures will vary for each environment, according to how virtualization is used and implemented.
It also lists the risks associated with using virtualization. Here's the PCI SSC's list:
Vulnerabilities in the Physical Environment Apply in a Virtual Environment
Hypervisor Creates New Attack Surface
Increased Complexity of Virtualized Systems and Networks
More Than One Function per Physical System
Mixing VMs of Different Trust Levels
Lack of Separation of Duties
Dormant Virtual Machines
VM Images and Snapshots
Immaturity of Monitoring Solutions
Information Leakage between Virtual Network Segments
Information Leakage between Virtual Components
For more about how virtualization affects complying with the PCI DSS, check out the document itself. It's actually fairly well written and understandable. It does assume that you understand what virtualization is and how it works, so if you're not comfortable with those concepts, you should probably be prepared to do a little background reading before looking at this particular document.
NIST just announced a proposal to approve two modes of format-preserving encryption for use in FIPS 140-2. Here's the announcement from NIST's web site:
Announcement of Proposal to Approve Two FFX schemes
June 9, 2011
NIST is pleased to announce a proposal to specify and approve two block cipher modes of operation for format preserving encryption (FPE). FPE is emerging as a useful cryptographic tool, whereby certain kinds of data, such as social security numbers or credit card numbers, may be selectively encrypted without changing their format. Consequently, FPE can be seamlessly retrofitted to existing applications to support the encryption of sensitive data.
Both of the modes that NIST proposes to approve are schemes that are compliant with the FFX framework that was submitted to NIST by Mihir Bellare of the University of California, San Diego, Philip Rogaway of the University of California, Davis, and Terence Spies of Voltage Security, Inc. The submission documentation for FFX is available at the modes development page, under the heading "Encryption Modes." The FFX framework is described in detail in the body of the specification [SP]. One FFX compliant scheme that NIST proposes to approve, called FF[radix] is specified in the addendum to the specification [SP2]. The second scheme that NIST proposes to approve, called VAES, is described in the additional documentation [AD] submitted by Joachim Vance of VeriFone Systems, Inc.
Also included in the documentation are Letters of Assurance from Voltage Security, Inc. and VeriFone Systems, Inc. [IP1 and IP2] in connection with intellectual property that those companies identified as possibly relevant to the implementation of FFX[radix] or VAES.
NIST proposes to recommend FFX[radix] as the preferred FPE scheme for interoperability. NIST will also consider approving other FFX schemes, in addition to VAES, on a case-by-case basis.
NIST requests comments on the proposal by July 8, 2011; comments may be submitted to EncryptionModes@nist.gov.
If NIST moves forward with the proposal, an additional period of public comment will be initiated on a draft special publication that specifies the modes.
FPE has proven to be very useful for encrypting data in complex legacy environments. In these situations, there's often at least one component of an installed system that can't easily handle encrypted data if its format if different than the plaintext. National governments are good examples of places where such complex legacy environments appear, so it's not too surprising that NIST is interested in approving FPE for government use.
There was an interesting ruling (PDF) by the United States District Court District of Maine in Patco Construction v. People’s United Banka few days ago. It seems that back in 2009, someone at Patco Construction managed to install Zeus malware on the computer that Patco used to initiate electronic funds transfers. This let hackers capture the answers to the challenge/response questions that Patco used to authenticate to their on-line banking system. The hackers then used this information to complete about $345,000 in fraudulent transactions. Patco sued to recover the lost money, claiming that the bank’s security measures were not "commercially reasonable." The court disagreed, and Patco’s suit to recover the money lost in the fraudulent transactions was dismissed.
What I find interesting about this particular ruling is part of why the bank’s security measures were found to be commercially reasonable. FFIEC’s guidance "Authentication in an Internet Banking Environment" (PDF) recommends multifactor authentication for financial transactions, but exactly what that means isn’t as clear as you might expect it to be. In this particular case, the bank claimed that in addition to a username and password plus the answers to challenge/response questions, that
its security procedures also employed "something the user has": device identification information specific to the client’s personal computer and its use of the Bank’s application, and "something the user is": taking into account user behavior.
But when the hackers compromised the username and password plus the challenge/response answers, they didn’t compromise these other factors. They didn’t get the ability to spoof device authentication information and they didn’t get the ability to spoof the behavior of the legitimate user. But that’s apparently OK. As the bank pointed out, in their legal arguments, Patco
attempt[ed] to manufacture an additional "requirement" for multifactor authentication, unsupported in the FFIEC guidance or in case law, by arguing that the system must respond in a certain way to each of the factors, for example, by blocking a transaction if one of the factors fails.
So it looks like the bank claimed, and that the court agreed, that it’s OK for some of the factors in a multifactor authentication to fail yet for the overall authentication to succeed. I haven’t carefully considered all of the implications of that, but my first reaction is that this is probably just an oversight on the part of the people who wrote the FFIEC’s guidance, and it’s something that the next version should probably address.
It also looks like people writing other standards should also think about this and consider explicitly requiring success from more than one of the factors in multifactor authentication for an authentication attempt to succeed. Maybe that’s something that the ASC X9F4 working group should consider, for example.
In the previous post about what Google trends tells us about the number of searches for "FIPS 140-2," I forgot to include the graph which weights the number of searches by the population of the countries. Here's what that looks like.
So while Americans are the source of more searches for "FIPS 140-2," Israelis are the source of more searches per capita, while Americans fall to a distant seventh place.
Today happens to be World IPv6 Day. According to research by Google, only about 0.2 percent of Internet users can actually use IPv6, so not much may really happen because of this event.
According to Google trends, here's the relative frequency of searches for the term "FIPS 140-2" by country. It looks like Americans are the biggest fans of it.
There are even a few cities where FIPS 140-2 seems to be popular. Here's the relative frequency of the search in the top 10 cities where it's searched for the most frequently.
There's been some discussion of the security implications of Unicode characters. In particular, some people worry that hackers could use Unicode characters to create strings that look just like other strings but behave very differently.
The Unicode U+006F ("o") looks a lot like the Unicode U+03BF ("ο"), for example, so that it's hard for people to tell the difference between "Google" and "Goοgle," even though they're actually different strings.
But there's a way to make Unicode even trickier, and that's by using the character U+202E, the "right to left override."
Here's the alphabet
ABCDEFGHIJKLMNOPQRSTUVWXYZ
and here's the alphabet with a single U+202E inserted in the middle of it
ABCDEFGHIJKLMNOPQRSTUVWXYZ
Note how the entire second half of the alphabet is displayed backwards when this single additional character is added. (If you can't see this, then your browser probably doesn't handle Unicode correctly. I tested it in IE 8 and Chrome 10 and it worked with both of them.)
And if you copy and paste the last three characters of the alphabet with the embedded U+202E, you'll find that when you select and copy the "PON" and paste it you get "NOP" back because the U+202E isn't in the part that you copied. You may think that you're selecting "PON," but you're really not.
Now imagine how a clever hacker could take advantage of this.
After yesterday's post about Google trends suggesting that South Korean is more interested in the Common Criteria than other countries are, I decided to look at the same data, but to then scale it by the populations of the countries.
Here's what I found. So when we look at the relative interest in the Common Criteria, it looks like Singapore comes out on top and Korea falls to sixth place.
According to Google trends, here's the relative frequency of searches for the term "Common Criteria" by country. It looks like Koreans are the biggest fans of it.
A recent copy of The Nilson Report noted that the business of payment cards, the global market share of China UnionPay (4.03%) is greater than the global market share of American Express (3.91%).
Amex is already involved in setting the security standards that govern the payments industry. Along with Discover, JCB, MasterCard, and Visa they're part of the PCI SSC, for example. But I haven't met anyone from UnionPay at any of the standards meetings that I go to. I haven't even seen their name on any list of members. But now that UnionPay is getting fairly big, maybe we'll see them more involved in setting security standards for the payments industry in the future.
To implement pairing-based cryptography, we want elliptic curve groups with a low embedding degree. These are actually fairly rare. The following result by Balasubramanian and Koblitz gives us a rough idea or exactly how rare they are:
Let q be a randomly chosen prime with M/2 ≤ q ≤ M and E/GF(q) a randomly chosen elliptic curve. If #E(GF(q)) = p for some prime p, then the probability that p | (qk – 1) for some k ≤ (log q)2 is less than c (log M)9 (log log M)2 / M for some constant c.
We can summarize what the BK theorem tells us as saying that the chances of an embedding degree being low (k ≤ (log q)2) are extremely small ((log M)9 (log log M)2 / M).
This doesn’t cover the exact case that we're interested in because we don't always have #E being a prime. That actually doesn't happen very often. But let's suppose that the same estimate is still valid for cases where #E isn't a prime and see how rare we can expect low embedding degrees to be.
Let's suppose that we want to find a curve that's suitable for use at the 128-bits-of-security level. At that level, q has at least 256 bits, so that the value M in the BK theorem also has at least 256 bits. At that point, the probability of a random curve having a low embedding degree is actually so low that you can expect it to essentially never happen: ignoring the constant c, we get the estimate that this probability is no more than 2-178.
That's only if you're picking a random curve, of course. If you're picking a curve by other means, you can still find ones with a low enough embedding degree to be useful. It's easy to find BN curves (embedding degree k = 12) at the 128-bit level, for example, but doing that isn't the same thing as picking a random curve.
And the bound of (log q)2 can actually be impractically big for useful sizes of q. If q has 256 bits then (log q)2 is roughly 2562 = 65,536, and implementing anything over such a GF(q65,536) isn't practical. An element of GF(q65,536) is a vector of 65,536 components, each of which has 256 bits, for a total of 16,777,216, or 224, bits. Those aren't practical to do public-key operations with.
The bottom line is that most elliptic curves aren't useful for pairing-based cryptography. So if you need a curve to use in this way, don't try to pick random curves until you find one that works. That's a very bad idea. Instead, just get one from the IEEE P1363.3 standard. Or if you don't want to do that, get a copy of "A Taxonomy of Pairing-friendly Elliptic Curves" by David Freeman, Michael Scott and Edlyn Teske. That should give you all that you need to find your own curve.
It looks like the IEEE P1363.3 Standard for Identity-based Public-key Cryptography using Pairings is finally complete. When we were working on the last part of this standard, the appendix that describes how to implement the low-level mathematical operations that are used to implement the pairing-based schemes that the standard specifies, there was some discussion about what types of parameters to recommend.
My opinion was that we shouldn't include anything that provides less that 112 bits of strength, because that's the generally accepted minimum today. That's what the US government's FIPS 140-2 requires (although they did get an extension until 2013 to actually move to the bigger keys). So according to the US government's policy, using less than the required strength is actually just like using no encryption at all from the point of view of complying with government regulations. So after 2013, one of the government's auditors can actually say that an agency had a data breach if they were using less that 112-bit encryption.
Some people in the P1363 group weren't convinced that the 112-bit strength minimum was really worth worrying about and wanted to included recommended parameters that gave less strength. I'm not convinced that including parameters for what's now considered an inadequate level of security is a good thing to do, but I may get outvoted on this.
To me, the reality of the legal and regulatory environment in which encryption is used makes at least 112 bits of strength a requirement for anything being done today. Others don't seem to agree with this, so we may end up with stuff in the P1363.3 standard that will probably never be used by anyone outside of academia because it doesn't meet today's generally-accepted requirements for security.
Which you can also get by going here.
People who haven't worked on standards often don't have a good understanding of exactly how slow and painful this can be at times. If this describes you, here's an excerpt from an email that I recently received that summarized the progress that was made one day on an hour-long conference call:
That should give you a pretty good idea of what it can be like sometimes.
The 2011 Key Management Summit is almost here. This year it's being held in Pacific Grove, California, right down the street from the Monterey Bay Aquarium, the Pebble Beach golf course and 17-mile Drive. Previous events were sponsored by the IEEE and were collocated with the IEEE MSST conference. But because key management has moved away from its roots in storage, this year's event isn't being held with MSST. It's not even an IEEE event this year. That means that the IEEE won't cover any losses that the event might suffer, so key management vendors Voltage, Thales and SafeNet volunteered to handle that responsibility. It's still an industry event, just one that vendors are picking up the tab for this time.
But there are more reasons to go to this event besides a nice location. It's a great chance to learn about key management from people working in academia, the government and industry. Each of these types of participants usually have very different points of view, and you can learn lots of interesting things from each of them.
The academic point of view might not be very helpful for solving today's key management problems, but it will probably a good indication of what's coming in five to 10 years.
The government speakers probably have some interesting things to say also. Some of the biggest key management systems in the world are run and used by government agencies, and the people behind these projects often have lots of interesting insights that are hard to find elsewhere.
And when it comes to knowing who's actually buying what, there's no better of point of view than that of the vendors who are making and selling key management solutions today.
From the most recent program for this event, it certainly looks like there are couple of excellent opportunities to hear things that will be of interest to anyone working in the information security field. These two talks look particularly interesting:
Dorothy Denning, Naval Postgraduate School, "The History of Key Management"
Dan Boneh, Stanford University, "Social Keys: New Directions in Public Key Management"
Back in the dot-com era, Dorothy Denning was one of the most vocal supporters of the Clinton administration's key escrow plans, which would have required all users of strong cryptography to use a version of the technology that the government could get the keys for and decrypt. With a court order, of course. She's seems to have changed her mind in the past 10 years or so, but it will still be interesting to hear her description of what really happened in the political battles over key escrow.
Dan Boneh is probably very well known to people in touch with the academic cryptography research community, although he might be less well known by people in the business world. In addition to being the inventor of the first practical and secure identity-based encryption scheme, he won the 2005 RSA Award for the field of mathematics for his work in public-key cryptography. He's one of the world's leading researchers in the field and can definitely give you a good idea of where academic research in data security is headed.
But it's not just academics that will be at this year's event. Here's a list of the other talks that are confirmed as of today:
Tony Steiber, Wells Fargo, "Crisis and Opportunity of Cryptographic Key Management"
Chris Kostick, Ernst & Young, "Auditing an Enterprise Key Management Project"
Elaine Barker, NIST, "Key Management Framework"
Ramon Krikken, Burton Group, "So we're managing a bunch of keys… now what?"
Bob Griffin, RSA, "The OASIS KMIP Standard: Interoperability for the Cryptographic Ecosystem"
Rami Shalom, SafeNet, "Universal Key Management in an Age of Encryption Fragmentation"
Bob Griffin, RSA, "Where Are My Keys?"
Jon Geater, Thales, "Key Management Control Strategies in the Cloud Information System"
Boris Schumperli, Cryptomathic, "A New Approach to Key Management in the Cloud"
A panel discussion on cloud key management, led by Ramon Krikken, Burton Group.
And even though it's not an official part of the event, the best part might actually be what you learn from talking to people working in the field over lunch or dinner. That's when you'll often learn all sort of things that you wouldn't hear in a more formal setting. Past events have also had very interesting discussions between the major key management vendors about which of their products were selling and which ones weren't. And at one past event, one leading key management vendor even learned from one of their biggest customers that they weren't happy with certain features of the vendor's products. The sort of stuff that you want to hear but that's hard to learn in other ways. For only $325, that's a pretty good deal.
But it's even better than it already sounds. (Try to imagine that being said by either Billy Mayes or Anthony Sullivan, the famous infomercial pitchmen.)
That $325 even includes a room at the Asilomar Conference Grounds and your meals while you’re at the meeting. I’m not part of the program committee for this year’s event because people didn’t want to see too much participation from a single vendor so I haven’t see the budget for this event, but I’m very surprised that they were able to do this for only $325. In many cases, just the cost of the meeting rooms and insurance that hotels make you get for events like this can put a floor of around $200 to $250 on what you can charge to break even, so the fact that they were able to get the meeting facilities plus a room and meals for only $325 is quite impressive.
And although the web page for the KMS doesn’t mention it, I’ve been told that attendees will also get a KMS 2011 t-shirt.
So there will be lots of interesting discussions and a cost that’s probably well below what you’d expect. Milton Friedman would probably suggest that you take this opportunity to buy something at a low price instead of selling something at a low price, and you can do that by signing up for this event here.
I was recently looking at FIPS 74, the old standard from 1981 that defined how to use the DES encryption algorithm. Section 5 of this document is "USING DES TO MAP A CHARACTER SET ONTO ITSELF," which seems to indicate that the idea of format-preserving encryption has been interesting to people since at least 1981. FIPS 74 may also be one of the first attempts to bypass spam filters.
In particular, FIPS 74 (at least in the version that's on the NIST web site) section 5 is called "IMPLEMENTATlON OF THE A1GOR1THM," which has the letters "L" and "I" replaced with a "1." The first spam email was actually sent in 1978, so 1981 is definitely within the Age of Spam.
I don't recall email discussions of encryption algorithms being particularly overwhelming back in 1981, but could the title of section 5 of FIPS 74 have been an early attempt by NIST to sneak their DES standard past spam filters, sort of like people do when they try to sell you "V!@gra" today?
I just came across another interesting You Tube video. This one has Bob Griffin of EMC talking about the Key Management Interoperability Protocol (KMIP), one of the many evolving standards that we'll be supporting in our products soon. Hearing Bob's five-minute pitch actually gives you a better idea of what KMIP is all about than any of the written documents that I've see so far, so if you don't know much about KMIP but want to learn about it, this might be a good place to start.
In a recent standards meeting, we wasted several hours arguing over what the definition of terms like "feasible" really ought to be. My solution was to move these tricky definitions into the section of the document that described its scope. Something like "This document must only be read by people who understand the meaning of the word 'feasible.'" Unfortunately, not enough others liked this idea, so we'll probably spend several more hours arguing about the meaning of these terms at the next meeting also.
After the recent post about the relationship between swearing and tolerating pain, some alert readers pointed out the fact that it's not just PKI that may be the cause of people swearing. In particular, they suggested that two additional activities that may tend to cause this: building and testing hardware as well as attending standards meetings.
Although I can personally vouch for the fact that working on hardware tends to make you swear a lot, I've noticed that there's very little swearing in standards meetings. That's usually reserved for the side meetings that always accompany the meetings: lunch, dinner, etc. And because there's usually a considerable delay between the actual pain and suffering and the swearing in the case of standards meetings, I don't think that they would really have worked very well for what the researchers were trying to discover, which was the connection between the perception of pain and swearing. In this particular case, the swearing seems to happen at least an hour or two after you feel the pain.
it looks like our marketing guys are having another webinar. This one's Understanding EMV – Future Directions for the U.S. Market, and here's a quick description of what it will cover:
Merchants, issuers and acquirers need to understand the elements that comprise EMV, how EMV adoption may impact PCI compliance initiatives and what additional security needs to be implemented to ensure comprehensive data protection from Point-of-Sale (POS) and Card Not Present (CNP) to back-end Merchant IT systems.
In this webcast you will learn:
Why EMV is gaining more awareness in the United States as the standard for securing interactions from the card to the payment terminal
What threats EMV is designed to mitigate and how EMV affects PCI compliance
Why organizations need to address the complete security of cardholder data across their back-end IT systems
This webinar will be October 12, 2010 at 11 am Pacific/2 pm Eastern and will last 60 minutes.
If that sounds interesting, you can register for this webinar here.
In one of the standards groups that we participate in there's now a big flame war going on over the meaning of the definition of "encryption." This is a particularly frustrating flame war because it's essentially over a mathematical definition and the people who don't quite understand this particular definition seem to think that if they just state their totally incorrect position loudly enough or often enough that it will somehow become true. I don't quite understand how people can argue about math like this, but the more I see of my high-school-aged son's textbooks, the more I understand how things like this can happen.
His state-of-California-approved writing textbook, for example, has a list of things that you should keep in mind as you read the book. One of these is essentially "How does reading this book make you feel?" When I pointed this out to my son he said, "I guess that this book makes me feel that this class is going to be a complete waste of time." In this particular case, I can't say that I disagree with him.
But there are even similar things in his other textbooks. Even the math book. I didn't ask my son how that particular book makes him feel, but it certainly makes me feel that there will be more flame wars in the future that are caused by people who didn't manage to actually learn much in their math classes.
At the X9F4 meeting last week, we started work on a new document that will define a set of criteria for the secure use of PKI by financial institutions. There was unanimous agreement that the document needed two major parts: one that covers PKI that uses digital certificates and one that covers PKI that doesn't. Identity-based encryption is an example of using public-key technology in a way that doesn't require certificates. Using raw public keys also does. I've seen lots of use of IBE, of course, but I've also seen a few uses of raw public keys. Others in the X9F4 working group had also seen examples of that, and it seemed to me that the uses that we'd seen of it fell into two general categories.
In one case, if you're protecting things that are of relatively low value, you might decide that using certificate-based PKI just isn't worth the cost and headaches that it can cause, but you still want the benefits that using public-key technology can give you. I've seen cases of where exactly that happens.
In the other case, there are also cases where people just don't trust a certificate-based system to protect things which are of extremely high value. I've never seen examples of that myself, but other working group members had, and I have to admit that I was a bit surprised by these particular use cases.
In 2009, Mihir Bellare and Phil Rogaway shared the ACM's prestigous Paris Kanellakis Theory and Practice Award for their creation of the idea of "Practice-Oriented Provable-Security." Here's the citation for the award that explains why they received it:
Historically, cryptographic schemes used in practice were designed in ad hoc ways and subject to failure. Practice-Oriented, Provable-Security (POPS), developed by Bellare and Rogaway in a series of papers in the 1990s, changed this, giving us the means to create high-assurance practical cryptography, meaning schemes that were backed by the theoretical guarantee of provable security while meeting practical needs and expectations.
Today, POPS-based schemes are cornerstones of Internet security, implemented in most communication security protocols and software - these schemes are used every time someone makes a credit card-based Internet purchase. Meanwhile, the models, techniques and approaches that Bellare and Rogaway introduced, including the random oracle model, have become the foundation of a new subfield of cryptography, inspiring a great amount of follow-on work. Their papers are amongst the most cited in cryptography and their work is discussed in dozens of textbooks.
Bellare and Rogaway changed the perception of theory in practice. Prior to their work, practitioners ignored theory or were even antagonistic to it. Today, they not only choose to implement and standardize proven-secure schemes, but make provable security a requirement in some of their calls for algorithms. That this requirement can be met owes much to Bellare and Rogaway's work.
In other words, Bellare and Rogaway created a framework for cryptographers to use to prove the security of their inventions and this framework is really the single thing that's most responsible for transforming cryptography from an art into a science.
Before POPS, the only way to ensure that a cryptographic scheme was secure was to wait a while to see if anyone could find a weakness with it. With the invention of POPS that's no longer necessary. It might even be a waste of time to wait to see if a weakness can be found because if there's a valid proof because the very existence of the proof tells you that there can't be one.
Many of the technologies that we use at Voltage have proofs of security. This includes both our Identity-based Encryption and Format-Preserving Encryption. The things that we use that don't have proofs of their security are just things that older standards define: techniques standardized before POPS typically don't have proofs of their security, but there's no really alternative to using them.
I'd hope that newer standards won't have this problem. All of the discussions that I've seen recently in various standards groups have required a proof of security before a new crypotgraphic scheme is taken seriously.
After some standards meetings I'm reminded of the movie Strictly Ballroom. In particular, the following bit of dialog from it:
(SCOTT HASTINGS is discussing his daring new dance steps with the corrupt Australian Dance Federation President BARRY FIFE.)
BARRY: Where do you think we'd be if everyone went around making up their own steps?
SCOTT: Out of a job.
Not too long ago, Amazon introduced its EC2 Spot Instances, a new approach to cloud computing. Here's how Amazon describes this:
Spot Instances are a new way to purchase and consume Amazon EC2 Instances. They allow customers to bid on unused Amazon EC2 capacity and run those instances for as long as their bid exceeds the current Spot Price. The Spot Price changes periodically based on supply and demand, and customers whose bids meet or exceed it gain access to the available Spot Instances. Spot Instances are complementary to On-Demand Instances and Reserved Instances, providing another option for obtaining compute capacity.
Essentially, EC2 Spot Instances lets you bid for unused time on Amazon's systems, and it's the first real step towards making computing a commodity service. I believe that the biggest impact of cloud computing will be from EC2 Spot Instances and similar offerings, but probably not in the way that most people would guess.
I really don't see cloud computing ever becoming a true commodity service. Despite all of the talk about standards for cloud computing, cloud vendors really have no incentive to make their technologies interoperable, so I doubt that we'll ever see it become a reality. The huge number of different national laws will also make it very difficult for cloud computing to ever become a true commodity. You'll always have requirements that certain data essentially can't leave national boundaries either due to regulatory restrictions or other political issues. I don't foresee an easy solution to these problems, so I don't foresee the market for cloud computing ever becoming quite like markets for other commodities. I doubt that we'll ever see things like derivatives and hedging for cloud computing, for example.
Instead, I see the real change that Amazon's offering will create is that people will start to question the value of computing and do a better job of trying to quantify it. After all, you really shouldn't be bidding for computing services if you don't really know how much the computing is really worth to you. Once businesses get accurate metrics for the cost and benefits of enterprise software, the enterprise software market will change dramatically.
I believe that the opportunity to buy cloud computing as a commodity, even on a relatively small scale, will get businesses to start thinking about exactly how much computing is worth to them. This will then lead them to think about exactly which applications are really worth their cost. Once they have more accurate metrics, I believe that they'll find that some enterprise computing simply isn't worth what they're paying for it. We'll eventually find that while some types of enterprise applications make sense, others don't.
This will lead to either the collapse of parts of the enterprise software market or some difficult times for some software vendors as they try to make their offerings add value that's substantially more than the cost of the software. The products that remain after this big shake up will be the ones that should have been there in the first place. The products that disappear will be the ones that never should have been deployed. What we'll be left with will be much more efficient that what we have today, and that increased efficiency will be one of the biggest benefits from cloud computing.
According to a recent article in The Wall Street Journal, more credit card information is being stolen from hotels than from any other industry. This probably explains why Marriott is now involved in ASC X9F, the group that writes information security standards for the American financial services industry.
I wasn't quite sure why Marriott decided to get involved in security standards. Few users of security technology do. Most just leave it to security vendors to figure out how things ought to work. In light of the recent WSJ article, Marriott's participation in X9F makes a lot more sense. Other users ought to follow their lead in this area and make sure that their voices are heard.
If you don't get involved in the definition of standards then you shouldn't complain about them once they're done.
It looks like a tokenization vendor has taken it upon themselves to organize a group of vendors to create a standard for tokenization and its secure implementation. Having a standard that describes tokenization and how to do it securely is definitely a good idea, but I'm not sure that a vendor-led group that's not part of any recognized standards organization is the best way to do this.
A group organized by a single vendor probably won't have decision making processes that are as transparent as those that established standards organizations have. This probably isn't good. Although all standards organizations have their problems, you at least have a known process by which these organizations create and review their standards. These processes may not be perfect, but they're at least well known, and they almost always try to keep any single vendor from unduly influencing the content of any particular standard. With vendor-led groups, however, there's often little attempt at transparency, and there may even be little incentive for the group to act on feedback that they get on their standard as it's being developed. This often results in standards that aren't as useful as they could be.
I also have to wonder why a vendor-led group is necessary in this particular case. The Accredited Standards Committee X9, the organization that creates the American National Standards for the financial services industry, is currently working on a standard (X9.119) that will define requirements for the secure implementation of tokenization. This X9 standard will only reflect the requirements of the financial services industry, but because that's the main user of tokenization, that really shouldn't be a problem. I'm fairly confident that an organization that specializes in standards for the financial services industry will have a better chance of creating a standard that reflects the needs of the financial services industry than an organization comprising tokenization vendors will.
I'm also a bit puzzled by the fact that many tokenization vendors don't seem to participate in X9 at all. Voltage has been an X9 member for quite a while, and both the X9 community as well as Voltage have benefitted from this. The other members of X9 have essentially received lots of free cryptography and security consulting from Voltage, and Voltage has received lots of useful information about exactly what the needs of its customers are in return.
I'm not sure why tokenization vendors don't actively participate in X9, and the fact that they don't makes me wonder how much they really understand the requirements of their customers and how well they'll be able to create a useful standard for the secure implementation of tokenization.
I'm fairly sure that Voltage will end up participating in this vendor-led effort to define a standard for secure implementations of tokenization, but from what I know now, I'm not sure that the standard that this group creates will be very useful. In this particular case, I hope that I'm wrong. That doesn't happen very often, does it?
Do we really need another tokenization standard in addition to X9.119?
 |
|||
|
|||
 |
