Ramon Krikken
BG Analyst
2 years at Gartner
15 years IT industry
Ramon Krikken is an analyst in the Gartner IT1 Security and Risk Management Strategies team. He covers software/application security; service-oriented architecture (SOA) security; structured and unstructured data security management, including data masking, redaction and tokenization...Read Full Bio
by Ramon Krikken | December 9, 2011 | Comments Off
My colleague Eric Ouellet recently published “Is OASIS KMIP Yet Another Hollow Key Management Standard?” (subscription required). In the note, he raises several important questions around KMIP becoming a widely adopted standard. I share his concerns, and will be touching on this as well in my upcoming note about key management.
Without going into the gory details, let’s just say that vendors’ intentions only get us so far. Ultimately, it’s the customers who, to a great extent, are in the captain’s chair.
My advice (or a plea) to end-user customers: if you have any encryption/crypto products (and if you happen to like the idea of KMIP, of course) could you tell the vendor you’d really appreciate it if they’d KMIP-enable them?
Not because KMIP is the end-all be-all key management standard, but simply because having a standard, even with shortcomings, that vendors can actually rally behind is good for everyone (compare: SNMP, X-509, PKIX, etc.) You don’t want to end up going from 10 proprietary key management solutions to 8 KMIP-enabled-but-each-managing-this-one-specific-proprietary-thing ones.
P.S. While you’re looking at KMIP, it also makes sense to look at it as the key management standard to use for internally developed encryption / crypto applications.
Category: Cloud Security Tags: cryptography, encryption, fiefdoms, key management, KMIP, OASIS, vendors
by Ramon Krikken | November 2, 2011 | Comments Off
Just published: the Gartner IT1 2012 planning guides [customer access only, although you can get a very good sneak peek into our thinking from looking at some of the tables of content].
The overall theme, perhaps to no surprise, is summarized as “the macro trends of volatility, multiplicity, versatility, and mobility underlie much of Gartner’s IT1 coverage in 2012.”
Besides the “2012 Planning Guide: Security and Risk Management,” those who work in my areas of coverage will also enjoy “2012 Planning Guide: Application Delivery Strategies,” “2012 Planning Guide: Data Management,” and “2012 Planning Guide: Mobile Strategies.” There are several others around collaboration, data center, identity, and cloud. My suggestion to IT professionals is to read at least the recommendations in each.
It looks like everyone’s gearing up for an interesting 2012 research calendar. And because nothing is set in stone until we start to write, we always welcome input on where to look next.
Category: Uncategorized Tags:
by Ramon Krikken | October 27, 2011 | Comments Off
XML Encryption – covered in the W3C XML Encryption standard – is broken.Researchers at Ruhr Bochum Uni have discovered [PDF] how to recover the plain text of an encrypted XML message. Without going into the full details (which you can find in the paper), this is a variant of an existing attack and exploits the fact that the encryption uses the AES-CBC cipher mode.
So let’s start with the bad:
- It’s definitely kaput. It’s not just “broken in some theoretical way,” no, it’s broken in practice. The attack takes an average of 14 attacks per plain text byte. Although it’s an online attack (see below), that’s still mighty fast.
But there’s some good news too:
- It’s detectable. The attack requires interaction with the service/intermediary that has the keys, and it causes errors in decryption and XML parsing. This means that if you’re watching (which most aren’t) you could see the attack take place.
- It’s fixable. The attack works because AES-CBC lacks authentication. A long-term change will be to change it out with something like AES-GCM. In the short term, it’s possible to require the use of authentication already specific in the standard (it’s entirely optional, which may make strict enforcement difficult).
- Fixing is feasible. XML Encryption is used for data in motion, and the algorithm can be changed out without being visible to the services and consumers … if you built them right and let the infrastructure take care of the crypto (and if you can convince business partners et al to also fix).
So my advice is: try to patch particularly critical services with the existing built-in authentication, and strictly enforce it if possible. Then, while working on a long-term fix, keep a close watch on the XML decryption points to see if any entity is causing excessive errors. Take action when such an event happens.
Let this also be a reminder to those who often say “encryption is the easy part” when talking about crypto systems. It’s not.
Category: Security Tags:
by Ramon Krikken | October 14, 2011 | 1 Comment
Yesterday at RSA EU 2011 I had a chance to present my “towards secure tokenization algorithms and architecture” talk, and it gave me an opportunity to validate some thoughts on the fundamentals of tokenization designs and attacks.
One of my slides covered some lines from the PCI tokenization guidance, which I believe are well-intentioned but missing the point. In short, the definition of what constitutes encryption-based tokenization does not jive with the reasons for making the distinction. Two excerpts:
- “[encryption-based tokenization is] where the token is mathematically derived from the original PAN through the use of an encryption algorithm and cryptographic key”
- “Where token generation is based on the use of cryptographic keys, compromise of the keys could result in the compromise of all current and future tokens generated with those keys. “
Reading the above, some observations, most of which I worked into the presentation:
- If the tokenization server is a black box, an external observer cannot tell the difference between random and encrypted tokens; strong encryption exactly creates cipher text that is indistinguishable from random.
- If the tokenization server is a black box, an attacker must compromise it to gain access – randomization or not – and will gain similar access to keys or token tables.
- If the critical factor in limiting the use of encryption is to prevent compromise of future tokens, the black box model allows key rotation to limit future token compromise.
- Even when randomization is used, pre-generation of token pairs [for performance] may result in the compromise of future tokens.
- The life time of a credit card number is short enough to account for dealing with breakthroughs in cryptanalysis.
- Some so-called non-encryption-based token algorithms [because of the strict way in which the guidance defines what is encryption] have plenty of vulnerabilities to put them on par with encryption-based tokens.
- Even random tokens have problems if they’re not designed right.
And, most importantly:
- Any tokenization creates a persistent mapping between tokens and originals. Even in the form of a token database, this is at the core a form of encryption.
So, for practical purposes, a good design (but only a good design) will have similar exposure regardless of whether the token function is encryption or non-encryption based.
Yes, I realize this doesn’t make guidance easier per se. Yes, I realize this actually creates some problems in how PCI-DSS treats and differentiates encryption and tokenization. But given the lack of research [and standards] in this area, I think it needs to be discussed.
Category: Security Tags: cryptography, encryption, keys, PCI-DSS, tokenization
by Ramon Krikken | September 9, 2011 | 1 Comment
The PCI SSC recently released the “Information Supplement: PCI DSS Tokenization Guidelines.” In the guidelines, the council describes various aspects of tokenization, including some desired security properties of the system and the tokens, as well as how tokenization may reduce PCI DSS scope (which is ultimately tokenization’s raison d’être). Anton Chuvakin already provides various comments in his “On PCI DSS and tokens” blog post, so I will focus on my area of interest: token security.
Although the PCI guidance document is clearly based on a thorough analysis of tokenization, it is not (yet) complete. The guidance defers to future guidelines when stating “The PCI SSC is further evaluating how these considerations may impact PCI DSS scope for reversible, encryption-based tokens,” although it does clearly state “note that where token generation is based on a reversible encryption method (where the token is mathematically derived from the original PAN through the use of an encryption algorithm and cryptographic key), the resultant token is an encrypted PAN.” I believe this is problematic on three levels: it uses too specific a definition of “encryption,” does not take into account overall token system design, and thus does not properly align its requirements with attacks and risks.
I will go into further detail on this topic – including if and how tokenization applies to applications other than payment card processing – at the upcoming RSA Europe conference. You can get a preview of my session “Towards Secure Tokenization Algorithms and Architectures” by listening to this podcast.
Category: Security Tags: PCI-DSS, security, tokenization
by Ramon Krikken | October 21, 2010 | 1 Comment
With tokenization being heralded as a PCI DSS knight in shining armor, many vendors are eager to rapidly develop and ship tokenization products and services. It is not encryption, is more secure because there is no key to steal, and enables you to decrease PCI DSS scope, or so the story goes … for now, because there is no guidance yet (other than the less-than-ideal “Visa Best Practices for Tokenization Version 1.0“) on what makes a tokenization design acceptably secure. Sure, we can design the architecture with standardized secure storage, secure channels, proper authentication and authorization, and auditing and logging, but the tokenization algorithm choice can also matter a great deal.
I discuss this topic in much more detail in my “Data Masking: Run-Time Data Aliasing” document, but at the heart of the matter is that tokenizing data and storing the mappings in a database is cryptography – it in essence creates a code book, and the strength of the code does matter. All too often I hear the “it’s not encryption: there is no mutual information between the original and the token” as the only requirement for a “secure token,” but it’s not as simple as that. A FIPS-validated random number generator (RNG) is theoretically the best choice, while optimizations (to increase storage, performance, and support distributed token systems) can easily weaken security. And although the industry is working on creating guidelines for credit card processing, it remains to be seen whether the optimizations that work for credit card number tokenization work for other data types.
So in short: without good standards to validate these algorithms, buyer beware! Ask vendors what their token-generating algorithms are, and be sure to analyze anything other than strong random number generators for security. Hopefully we’ll soon see some good guidance from the PCI council and standards bodies. And if you are a Gartner IT1 customer, feel free to set up a dialogue to discuss the tokenization solutions you may want to evaluate.
Category: Uncategorized Tags:
by Ramon Krikken | September 8, 2010 | Comments Off
In my previous post I discussed some of the strengths and weaknesses of payment card substitute token generation, and now it’s time for an architectural question: in how far can the use outsourcing of card entry and token generation reduce PCI scope in the card-not-present environment?
If the merchant hosts all of the payment entry and interfaces the card data directly with the processor, we know the the whole application/system is in scope because it handles card information. Now let’s think of two alternatives:
- The merchant hosts card entry, but uses tokenization by having an AJAX call (JavaScript) or some other method to tokenize the card data right after it’s entered.
- The merchant outsources card entry and links to it from their site, using code on the outsourced site to have the client inject the token back into the merchant application.
In the first case there is still card data entering the merchant application, in the second there is not. Seems like quite the difference, right? Perhaps in implementation there is, but if you image the attack possibilities when someone compromises the merchant application the difference in results may be smaller than a first glance would indicate.
This is not to say that fully outsourcing the card entry doesn’t have other advantages, but given the attack environment the question of scoping is certainly not trivial … although in the practical world compliance is of course to a large extent in the eye of the QSA.
P.S. please note that this is not to pick on tokenization and card entry / processing outsourcing, but an example of the difficulty of scoping questions of which there are several once we get to the application layer.
Category: Uncategorized Tags:
by Ramon Krikken | August 13, 2010 | 2 Comments
VISA recently published its “Best Practices for Tokenization Version 1.0” (PDF) and there has been plenty of discussion about what’s in it. I won’t repeat it here, but for example the comments in Avivah’s post here speak for themselves: there are a lot of different aspects to discuss.
I’ll stay away from the discussion about what to call things other than to say that I think the term “pseudonymization” ultimately best describes the approach. Unfortunately we won’t soon agree on terminology. But I digress.
One of the major concerns I’ve seen is VISA treating the different token generation methods as identical. That is, it seems like you can use format-preserving encryption or non-encryption (such as randomization and linear counters) methods interchangeably. Is this OK? Well, perhaps, and perhaps not.
I don’t agree with treating them as identical. After all, in encryption you could get access to current and future card numbers if you steal the key. But for practical purposes I have to wonder about risk in token services: in such a setup they key exists only in the token server(s), which presumably use HSMs and other mechanisms to keep the keys secure.
If someone extracts the keys from such a system the organization has bigger problems than what token generation method it uses, and the types of attacks and access needed to steal keys would likely also fully compromise a lookup-table-based token server. In other words, it would probably be game over for both implementations.
That of course leaves attacks on the encryption algorithm itself, which is always a possibility. Although it’s possible that such an attack emerges, erosion of algorithms usually happens over time, and the lifetime of a credit card number is a few years at best (which could give enough advance warning to make changes before the end of the cryptoperiod of the tokens).
The big question of course is why you’d want to use encryption anyway. Randomization is theoretically more secure. A good reason would be to avoid performance and synchronization issues. Lookup tables are slower, and may need to be kept synchronized (and tokens unique) across token servers. Using encryption avoids the synchronization and uniqueness issues in particular. It’s possible to design good distributed token algorithms using randomization, but there will always be tradeoffs.
By the way, I think it’s interesting that the VISA document doesn’t mention key rotation requirements for encryption-based tokenization, but I think that may be related to a) the infeasibility of doing so without changing the token value, and b) the key being solely inside the token server. Still makes me wonder how long they PCI-DSS key rotation requirement can stand.
So let’s get to the question: should you tokenize using randomization or encryption? I think for now the short answer is: randomize where you can, but don’t discount format-preserving encryption just yet. There is no one-size-fits all, and we’ll of course have to see what the final PCI-words on this are.
Category: Uncategorized Tags:
by Ramon Krikken | May 19, 2010 | Comments Off
After a blogging hiatus I’m back – now on the GBN. To start I’m linking some of my favorite posts from the old blog:
Will 2010 be “the year of the data?”
Static Analysis: How Important is Accuracy?
Measuring Security Performance, Part II
New posts to follow soon; I have a back-log of topics!
Category: Uncategorized Tags:
