According to the data from statcounter.com, the Symbian operating system is still more popular than the ones that we hear about in the news so much: iOS and Android. That might change in a year or so, however.
That probably explains why most attacks on mobile devices target Symbian, doesn't it?
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.
Attention is essentially a cognitive faculty with a very well-marked ethical component, because to be ethical to you, I need to be attentive to your needs and desires. I need to be aware. We cannot be kind and considerate without paying attention to others. If I am distracted, you are an abstraction, you are not a real person. Attention is necessary for civility.
P. M. Forni, The Thinking Life: How to Thrive in the Age of Distraction
As a follow-up to yesterday's post, this might explain some of the behavior that we see on the Internet today.
What information consumes in rather obvious: it consumes the attention of its recipients. Hence a wealth of information creates a poverty of attention, and a need to allocate that attention efficiently among the overabundance of information sources that might consume it.
Herbert A. Simon, "Designing Organizations for an Information-Rich World," Computers, Communication and the Public Interest (1971)
Note the date of this. It's well before the rise of the Internet. But it was apparently just as true back then as it is today.
I wsa just looking through my old copy of Computer Parables. Even though this book was published in 1989, well before the dot-com era, it seemed to understand what the Internet would one day become:
"A programmer once built a vast database containing all the literature, facts, figures, and data in the world. Then he built an advanced querying system that linked that knowledge together, allowing him to wander through the database at will. Satisfied and pleased, he sat down before his computer to enjoy the fruits of his labor.
After three minutes, the programmer had a headache. After three hours, the programmer felt ill. After three days, the programmer destroyed his database. When asked why, he replied: “That system put the world at my fingertips. I could go anywhere, see anything. Because I was no longer limited by external conditions, I had no excuse for not knowing everything there is to know. I could neither sleep nor eat. All I could do was wander through the database. Now I can rest.”
Looking back at the dot-com era, it might be no coincidence that this parable was called "The Navigator."
The economics of cloud computing is based on the assumption that cloud providers can get better deals on things like servers and power than smaller businesses can because the cloud providers buy things in huge quantities. The best discussion that I've seen of this is Microsoft's "The Economics of the Cloud" (PDF). This white paper claims that the biggest area in which cloud providers have an advantage is in the area of cheap power. It also says that this is becoming the biggest component of the cost of IT.
So an obvious question to ask is this: at what point should we expect to see cloud providers generate their own power?
A typical power plant might produce roughly 1,000 MW, while a typical server might consume something like 500 W. This means that a single power plant can probably keep about 2 million servers running. (Maybe it's really more like half that number once you look at how much you need for air conditioning, etc.)
But industry estimates already say that Google isn't far from having that many servers. They're probably over half way there. (Other cloud providers seem to be behind by a factor of 10 to 20 or more.) So it shouldn't be too surprising if we start to see cloud companies thinking about generating their own power. Google might already be doing this.
"The computer industry is the only industry that is more fashion-driven than women's fashion."
Larry Ellison
Ten meaningless bonus points if you know what Ellison was talking about when he said this. Using a search engine gets you disqualified for cheating, of course.
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
*** Only 23 spaces left ***
Voltage Security invites you to "Voltage Security Live 2011" at Bridgewaters in New York City on November 9, 2011. This customer summit will focus on data-centric security and will feature several leading Voltage customers, such as American Express, Wells Fargo, State Street and others, who will discuss how they have implemented encryption projects for email encryption, data-centric encryption and end-to-end payment encryption. Also presenting will be Eric Ouellet, research vice president with Gartner Group, who is currently working on a new analysis of how companies use encryption. The goal of the summit is to enable Voltage customers to network with each other and pick up valuable best practices.
Stop Press: Thanks to our sponsors - Coalfire, OpenPath, Teradata and Thales, we are able to offer registration for eligible particpants at no cost. Register now at www.voltage.com/live
Join Voltage customers including: ADP, American Express, Bank of America, AT&T, Citigroup, Deloitte, Deutsche Bank, Elavon, Fidelity Investments, Heartland, JPMorgan Chase, McGraw-Hill, UBS and Wells Fargo.
.
Highlights of the agenda include:
Stop Press: Thanks to our sponsors - Coalfire, OpenPath, Teradata and Thales, we are able to offer registration for eligible particpants at no cost. Register now atwww.voltage.com/live
I just came across an interesting use for cell phones - avoiding people. According to a recent study (PDF) by Pew Internet,
Cell phones can help prevent unwanted personal interactions – 13% of cell owners pretended to be using their phone in order to avoid interacting with the people around them.
That's a use for cell phones that I didn't quite expect. In retrospect, I suppose that I shouldn't have been too surprised by this particular finding. Although nobody that I know has admitted using their cell phone in this particular way, some have admitted that they commonly text people to avoid talking to them. So maybe this is just the next logical step in that direction.
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.
To some, mainframes are seen as dinosaurs, technology that is obsolete or should be. However, this veteran platform has shown its resilience in enterprise computing for a reason. The benefits it offers to the corporate infrastructure - extreme scalability, high throughout, high availability - are matchless.
However, as IT executives responsible for running mainframes or other platforms with z/OS can attest - there are issues regarding complexity. For example, traditional encryption solutions can require hundreds of lines of code to acquire and store keys and perform cryptographic operations. And that isn't even the biggest problem; it's the knowledge required of all the moving parts of an application to ensure effective operation. And of course, with all that code and other complexities, there's more room for error.
That's why developing an encryption solution based on Format-Preserving Encryption to address the mainframe environment was an interesting challenge - and it's been met.
In response to customer requests, Voltage has now developed command line tools and a simple API that dramatically reduces the number of lines of code needed - from hundreds to just three. Now, companies of all sizes benefit from using Format-Preserving Encryption on the mainframe, including the ability to "encrypt here, decrypt there." This helps avoid the ASCII/EBCDIC issues that plague most cross-platform encryption solutions.
But that's not all. Engineers at IBM Hursley - the software development lab in Winchester, U.K., home to many of these technologies - point out that 80% of z/OS customers use CICS, the transaction server that's critical for mainframe operation. Unfortunately, many vendors still don't support CICS. Even IBM, which provides advanced encryption interfaces built into z/OS, has no developer abstraction to make it easy to encrypt within CICS environments. Traditional solutions for encrypting data rely on POSIX facilities, which are incompatible with CICS.
Now, in a major step forward for cryptographic operations encompassing CICS and other z/OS environments, Voltage is introducing z/Protect, part of the Voltage SecureData product family. z/Protect provides even higher application data-level abstraction, requiring just one line of code to accomplish what used to take hundreds. More to the point, no one likes to mess with mainframe applications, and the z/Protect approach means even fewer modifications.
To learn more about this innovative approach, which perfectly complements IBM's advanced cryptography on z/OS, here's a presentation introducing Voltage SecureData z/Protect.
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.
According to the Ernst & Young's 2010 Global Information Security Survey, not that many businesses are currently using cloud computing: only 23 percent of businesses surveyed are currently using it. But when they do get around to using it, most of them plan to do it themselves instead of using a cloud computing vendor. According to this survey, here are the types of cloud offerings that they plan to use:
At the J.P. Morgan Technology Innovation Symposium, yesterday afternoon, JPMorgan Chase inducted Voltage Security into its Innovation Hall of Fame in front of hundreds of Silicon Valley executives.
Only two vendors were selected in this year's awards which recognize top emerging technology vendors for business impact, measured in terms of driving value for the firm, disruptiveness of technology and the overall quality of the partnership. Voltage was selected by top IT executives at JPMorgan Chase for its innovative data-centric encryption approach for protecting structured and unstructured data across datacenters, the cloud and mobile devices.
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.
Not much of the field of information security can really be considered a science. The only part that can is cryptography. Here's how the JASON group report Science of Cyber-security (PDF) described this:
Cryptography, which examines communication in the presence of an adversary and in which the assumed power of that adversary must be clearly specified is viewed today as a rigorous field, and the approaches pursued in this area hold useful lessons for a future science of cyber-security.
Now if we could just make the rest of the field just as rigorous, lots of our problems would get much easier.
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
Because the 20th anniversary of the World-Wide Web was just a few days ago, I thought that I should commemorate this event by trying some of the older web browsers to see how well they would work today.
I first tried the Voltage web site. Here's what it looks like in the pre-dot-com-era Mosaic 1.0. It's clearly not optimized for that particular browser, is it?
It actually turned out to be fairly hard to find a web site that actually doesn't look really bad in Mosaic 1.0. The web sites that once had links to text-only sites haven't been updated in quite a while and almost all of the sites that they once linked to are gone.
But I finally found one that worked - the web site of the Kennedy Center. Here's what it looks like in Mosaic 1.0.
Now that's a user experience that I hadn't had in quite a while. Back in the pre-dot-com era things weren't as fancy as today's Internet, but they were definitely a lot less annoying. No advertising. And no social networking sites.
According to an article on the IEEE Spectrum Risk Factor blog, people in the state of Massachusetts are being inconvenienced a bit by the error rates of a biometric system that the state uses to identify people suspected of having a fake identity. Here's how Spectrum summarized what happened in one particular case:
John H. Gass is still not a happy person. On the 5th of April, he received a letter dated the 22nd of March from the Massachusetts Registry of Motor Vehicles telling him that his driving license had been revoked, and that he must immediately stop driving.
Mr. Gass, who had not received a traffic violation for years, was identified by the RMV as a person suspected of having a fake identity by an automated anti-terrorism facial recognition system, an article in the Boston Globe reported. At least 34 other states use the same or similar software, the Globe says, much of it paid for in part by grants from the US Department of Homeland Security.
It turns out that the face recognition software flagged Mr. Gass's picture as looking like another Massachusetts driver, hence the letter from the Massachusetts RMV. The Globe says that it took Mr. Gass ten days of wrestling with the RMV bureaucracy to prove to them that he was indeed who he said he was before he was able to get his license back.
According to the Globe story, based on results of the recognition system, last year the "State Police obtained 100 arrest warrants for fraudulent identity, and 1,860 licenses were revoked as a result of the software."
Neither the Spectrum article nor the Globe article that it refers to say how many off those arrest warrents and license revocations turned out to be due to the non-zero false match rate for the facial recognition system that the state government uses.
Based on the error rates of biometric systems that I'm familliar with, I wouldn't be surprised if Mr. Gass isn't alone in having a problem with being inaccurately identified by one of these systems. The Globe article leads you to believe, however, that the state isn't very sympathetic in these situations at all. It quotes a state spokesman saying that, "protecting the public far outweighs any inconvenience Gass or anyone else might experience."
I just came across an interesting article (and podcast) on the IEEE web site. It seems that a team of researchers at Cornell have found a way to tell truthful on-line reviews from the fake ones that are sometimes called "opinion spam".
A quick summary of what they found is that people write differently when they're writing fiction versus non-fiction, and it's possible to use this as the basis for detecting bogus on-line reviews.
You can get slides that the researchers used at a recent presentation about their findings here (PDF). There's a lot missing from the slides, but there's enough there to get a reasonable idea of what they found and how they found it.
I don't know how current this information it, but the database of side-channel attacks that's available at sidechannelattacks.com seems to show that there's not much work being done in this area now. It looks like research into side-channel attacks peaked back in 2006 and has steadily declined ever since.
Why are side-channel attacks no longer interesting to researchers?
Extreme hardware hacker Ben Krasnow has come up with another extremely clever creation - a homemade scanning electron microscope. You can find an overview of this project in this video:
The total cost of this project was about $1,500. The image quality isn't quite what you'd expect from the commercial models, but it's also over a factor of 1,000 cheaper. I seem to recall that the last SEM that I used cost about $2.1 million, and that was more than a few years ago.
And because a SEM is a great tool for hackers to use to attack secure microprocessors, like the ones that you find in smart cards, it certainly looks like it's now not too hard for clever hackers to build the tools that they need to hack secure hardware instead of buying them.
That's assumes that they're as clever as Krasnow, of course.
But it certainly looks like sophisticated attacks against secure hardware are getting much easier and cheaper to carry out. Before too long, it might even be reasonable to start worrying about exactly what level of protection they're actually providing.
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.
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.
Mike Scott, the researcher who's responsible for lots of the optimizations that make it possible to efficiently implement the pairings that pairing-based cryptography uses, has set another record. His new record is for a BB1 decryption at the 256-bit security level on a 64-bit Intel i5 520M running at 2.4 GHz in about 44 ms. That's very impressive.
When pairing-based cryptography was relatively new, calculating a pairing was fairly expensive, which made PBC unattractive for many applications where the computing power of a desktop PC or server wasn't available. The work of Scott and others has essentially removed that obstacle to the widespread use of pairings, so they may be showing up in lots of other areas soon.
There's also more interesting material in Scott's paper ("On the Efficient Implementation of Pairing-Based Protocols") that describes this record. Here's how he describes what it tells us, just in case you're undecided about whether or not you should read it:
The advent of Pairing-based protocols has had a major impact on the applicability of cryptography to the solution of more complex real-world problems. However there has always been a question mark over the performance of such protocols. In response much work has been done to optimize pairing implementation, and now it is generally accepted that being pairing-based does not preclude a protocol from consideration as a practical proposition. However although a lot of effort has gone into the optimization of the stand-alone pairing, in many protocols the pairing calculation appears in a particular context within which further optimizations may be possible. It is the purpose of this paper to bridge the gap between theory and practise, and to show that even complex protocols may have a surprisingly efficient implementation. We also point out that in some cases the usually recommended pairing friendly curves may not in fact be optimal. We claim a new record with our implementation of a pairing at the AES-256 bit level.
I was talking to some of the engineers who work on our encryption product for RIM's BlackBerrys this morning when we digressed from encryption into general characteristics of the cell phone market. This led me to look for some data about what fraction of cell phones are 2G and what fraction are 3G. I found the following data in the ITU's The World in 2010 (PDF). I was surprised to see that so few phones are 3G today.
Researchers in Singapore and Norway have just shown how it's possible to eavesdrop undetected on a communications link that's protected by one particular implementation of quantum cryptography. This isn't an attack on quantum cryptography in general. Instead, it's an attack on a particular implementation of a particular type of quantum cryptography.
This ought to be sounding very familiar to anyone with more than a casual interest in cryptography. Without the word "quantum," this really describes lots of attacks that have made the news in the past few years in which someone finds an attack that doesn't work in general, but works against one particular implementation of one particular type of cryptography.
Here's how the researchers describe their work:
The stated goal of quantum key distribution (QKD) is to grow a secret key securely between two parties with a minimum of additional assumptions. The number of assumptions has been continuously reduced, from requiring the validity of quantum mechanics in early QKD, to more general constraints on the laws of physics in device-independent QKD. Despite steady theoretical progress in dealing with known limitations of current technology, in practice the security of QKD relies not only on the quantum protocol but on the physical implementation. A variety of attacks have been conceived to exploit weaknesses of current systems. Here we demonstrate the first full field implementation of an eavesdropper attacking an established QKD connection. The eavesdropper obtains the complete 'secret' key, while none of the results measured by the legitimate parties indicate a breach in security. This confirms that non-idealities in physical implementations of QKD can be fully exploitable.
As we often see with quantum cryptography, there's a certain amount of spin involved in how the work is described. Here's what one of the researchers said about the implications of this work:
"Quantum key distribution has matured into a true competitor to classical key distribution. This attack highlights where we need to pay attention to ensure the security of this technology," says Christian Kurtsiefer, a professor at the Centre for Quantum Technologies at the National University of Singapore.
The claim that quantum cryptography has matured into a true competitor to classical key distribution is a good example of this type of spin. That's really just wishful thinking on the part of researchers who want to get funding for their future work. Except for a few proof-of-concept systems, we probably won't be seeing quantum cryptography used much in the near future. It just doesn't solve any problems that people are willing to pay to have solved. At least not yet.
I just came across an interesting paper about the security of medical implants. It seems that much like the Internet, medical implants weren't designed with security in mind, and "They Can Hear Your Heartbeats: Non-Invasive Security for Implantable Medical Devices" (PDF) by Shyamnath Gollakota, Haitham Hassanieh, Benjamin Ransford, Dina Katabi and Kevin Fu describes a way that they've developed to work around some of these issues. Here's how the abstract of this paper describes their work:
Wireless communication has become an intrinsic part of modern implantable medical devices (IMDs). Recent work, however, has demonstrated that wireless connectivity can be exploited to compromise the confidentiality of IMDs’ transmitted data or to send unauthorized commands to IMDs—even commands that cause the device to deliver an electric shock to the patient. The key challenge in addressing these attacks stems from the difficulty of modifying or replacing already-implanted IMDs. Thus, in this paper, we explore the feasibility of protecting an implantable device from such attacks without modifying the device itself. We present a physical-layer solution that delegates the security of an IMD to a personal base station called the shield. The shield uses a novel radio design that can act as a jammer-cum-receiver. This design allows it to jam the IMD’s messages, preventing others from decoding them while being able to decode them itself. It also allows the shield to jam unauthorized commands—even those that try to alter the shield’s own transmissions. We implement our design in a software radio and evaluate it with commercial IMDs. We find that it effectively provides confidentiality for private data and protects the IMD from unauthorized commands.
So it looks like lots of medical implants have wireless connections that doctors can use to communicate with them. And because hackers could also use these same wireless connections to hijack the implants and have them do bad things, it's reasonable to worry about their security. That's something that I hadn't considered before.
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.
It looks like Craig Costello and Kristin Lauter have found a way to implement operations on hyperelliptic curves of genus 2 that's faster than previous approaches. Here's how the abstract for their paper decribes this:
We derive a new method of computing the composition step in Cantor’s algorithm for group operations on Jacobians of hyperelliptic curves. Our technique is inspired by the geometric description of the group law and applies to hyperelliptic curves of arbitrary genus. While Cantor’s general composition involves arithmetic in the polynomial ring F_q[x], the algorithm we propose solves a linear system over the base field which can be written down directly from the Mumford coordinates of the group elements. One advantage to our approach is that we get explicit formulas for composition without unrolling the loop in Cantor’s algorithm which includes steps operating on polynomials in F_q[x] such as the Chinese Remainder Theorem. We give more efficient formulas for group operations in both affine and projective coordinates for cryptographic systems based on Jacobians of genus 2 hyperelliptic curves in general form. We also examine several other consequences of using the geometric picture of Jacobian arithmetic for various genera.
I'm not convinced that there's any compelling reason to use hyperelliptic curves instead of elliptic curves, at least when it comes to implementing cryptography, but it's always interesting to see progress made in clever ways to implement operations on them.
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.
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.
There's an interesting paper on the IACR's Cryptology ePrint Archive - "Identity-Based Cryptography for Cloud Security." Here's a summary of what it talks about:
Abstract—Cloud computing is a style of computing in which dynamically scalable and commonly virtualized resources are provided as a service over the Internet. This paper, first presents a novel Hierarchical Architecture for Cloud Computing (HACC). Then, Identity-Based Encryption (IBE) and Identity-Based Signature (IBS) for HACC are proposed. Finally, an Authentication Protocol for Cloud Computing (APCC) is presented. Performance analysis indicates that APCC is more efficient and lightweight than SSL Authentication Protocol (SAP), especially for the user side. This aligns well with the idea of cloud computing to allow the users with a platform of limited performance to outsource their computational tasks to more powerful servers.
In other words, technologies like IBE may be better suited for use in cloud computing than alternatives because they scale better and are easier to use. It's an interesting paper if you're interested in those sort of things.
Craig Gentry, who recently invented the first fully-homomorphic encryption scheme, has invented another way to do FHE. This is described in "Fully Homomorphic Encryption without Bootstrapping." Here's the abstract from this paper:
We present a radically new approach to fully homomorphic encryption (FHE) that dramatically improves performance, bases security on weaker assumptions, and does not require Gentry's bootstrapping procedure.
Specifically, we offer a choice of FHE schemes based on the learning with error (LWE) or ring-LWE (RLWE) problems that have 2λ security against known attacks. For RLWE, we have:
- A leveled FHE scheme without bootstrapping that can evaluate L-level arithmetic circuits with (Õ·L3) per-gate computation - i.e., computation quasi-linear in the security parameter. Security is based on RLWE for an approximation factor exponential in L.
- A leveled FHE scheme that uses bootstrapping as an optimization, where the per-gate computation, which includes the bootstrapping procedure, is Õ(λ2) (independent of L). Security is based on the hardness of RLWE for quasi-polynomial factors (as opposed to the sub-exponential factors needed in previous schemes).
We obtain similar results for LWE, but with worse performance. For circuits of large width - e.g., where a constant fraction of levels have width at least λ - we can reduce the per-gate computation of the bootstrapped version to Õ(λ), independent of L, by batching the bootstrapping operation.
Previous FHE schemes all required Ω(λ3.5) computation per gate. We eliminate bootstrapping and improve performance using the same technique - namely, a much more effective approach for managing the noise level of lattice-based ciphertexts as homomorphic operations are performed. This new noise management approach uses tools recently introduced by Brakerski and Vaikuntanathan.
The bootstrapping that previous ways to do FHE required also made them fairly slow - too slow to be practical. But Gentry remarks in a footnote in this paper that:
We are aware of the seeming irony of trumpeting "FHE without bootstrapping" and then proposing bootstrapping "as an optimization". First, FHE without bootstrapping is exciting theoretically, independent of performance. Second, in terms of performance, whether bootstrapping as an optimization actually improves performance depends on the number of levels in the circuit one is evaluating; for circuits of depth sub-polynomial in the security parameter, this "optimization" will not improve performance asymptotically.
So I'm left with the impression that this is probably just a theoretical breakthrough instead of a practical one. But with the steady progress being made in FHE, it may not be long until it's actually practical. But it looks like we're still not quite there yet.
I just read Chief Excutive magazine's annual Best/Worst States for Business survey and learned that for the seventh year in a row, California placed dead last - 50 out of 50. You can find details on the rankings of the states here.
Silicon Valley has managed to create lots of game-changing innovations over the past few decades. What sort of innovations have we missed out on because it's become more difficult to do business in the Valley since the dot-com boom?
One of the letters to the editor that appeared in this week's issue of The Economist had an interesting analogy for the security of cloud computing. This letter was from Milo M. K. Martin, who said:
Car crashes are responsible for more deaths, yet a plane crash is certain to make the news. For the same reason, cloud computing outages are considered newsworthy. Although the frequent down times of companies’ internal IT systems are less publicised, these down times almost certainly cause more harm and lost productivity in aggregate (like car accidents).
This is one of the better analogies that I've heard for cloud computing. Both in terms of numbers of incidents and total overall impact, there are more security problems from tradition IT than from cloud computing, yet the cloud incidents often get more press coverage.
And to carry Martin's analogy a bit further, just like aviation is now a useful part of our transportation infrastructure, cloud computing will probably become a useful part of our future IT infrastructure. And just like it doesn't make sense to send everying by plane today, it won't make sense to use cloud computing for everything 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 turns out that transistors eventually wear out, much like mechanical components of a machine do. There was an interesting article about this in this month's IEEE Spectrum magazine. This was "An Odometer for CPUs" by John Keane and Chris Kim. There's an on-line version of this article here.
It turns out that there are actually three different ways in which transistors wear out: hot-carrier injection, bias temperature instability and oxide breakdown. Here's how Keane and Kim described these:
Over time, charge carriers (electrons for negative, or n-channel, MOSFETs; holes for positive, or p-channel, MOSFETs) with a little more energy than the average will stray out of the conductive channel between the source and drain and get trapped in the insulating dielectric. This process, called hot-carrier injection, eventually builds up electric charge within the dielectric layer, increasing the voltage needed to turn the transistor on. As this threshold voltage increases, the transistor switches more and more slowly.
There's a second mechanism that can also trap charge in the dielectric, and it doesn't require any current to flow between the source and drain. Whenever you apply voltage to the gate, a phenomenon called bias temperature instability can cause a buildup of charge in the dielectric, along with other subtle problems. After that gate voltage is removed, though, some of this effect spontaneously disappears. This recovery occurs within a few tens of microseconds, making it difficult to observe during routine experiments, where you stress the transistor but measure the resulting effects only after the stress is removed.
Yet another aging mechanism comes into play when a voltage applied to the gate creates electrically active defects, known as traps, within the dielectric. If they become too numerous, these charge traps can join and form an outright short circuit between the gate and the current channel. This kind of failure is called oxide breakdown, or more verbosely, time-dependent dielectric breakdown. Unlike the other aging mechanisms, which cause a gradual decline in performance, the breakdown of the dielectric can lead to the catastrophic failure of the transistor, causing the circuit it's in to malfunction.
So even if Moore's law stops making your computers obsolete after a few years, it looks like you'll still have to replace them after not too long because their transistors will actually wear out.
And when I read this article I had to wonder how transistors wearing out could affect side-channel attacks on encryption hardware. It's certainly possible that a piece of encryption hardware could be fairly resistant to side-channel attacks when it's new but gradually become vulnerable to them as it ages.
The second day of the 2011 key Management Summit was much different from the first day, and in more ways that one.
It seems that scheduling conflicts at the Asilomar Confernce Grounds kept us from using the same room for both days. The first day's room was fairly nice. The second day's room wasn't quite so nice. In particular, a hive of bees happened to live right above one of the exits. Some of the bees managed to fly into the conference facility, and after realizing that they were trapped inside, they'd buzz angrily as they flew into our room's glass windows in a vain attempt to escape.
The result was a situation much like the part of The Exorcist in which there's a loud buzzing sound in the background for a few minutes. Ours just lasted all day. But we didn't actually have to listen to the bees buzzing all day because our meeting was interrupted by a fire alarm.
It wasn't clear exactly why the fire alarm was triggered, although there was some speculation that it was due to someone smoking a cigarette somewhere on the nearby 17-Mile Drive. (The meeting was held in California, after all.) And after we restarted the meeting after the fire alarm, a plumbing failure on the grounds of the conference center nearby left us without water for a few hours.
So the people giving the talks on the second day were in a much tougher position. If you gave your talk on the first day of the 2011 Key Management Summit, the content of your talk was enough to keep the attention of the attendees. But if you talked on the second day, you ended up competing with bees, fire alarms and water shortages, and in that environment it was much tougher to get and keep people's attention.
But the speakers certainly tried their best to do just that. They all focused on how key management can support the secure use of cloud computing, which is certainly a topic that's of interest to lots of people today.
Bob Griffin of RSA gave two talks, "The OASIS KMIP Standard: Increased Interoperability for the Cryptographic Ecosystem" and "Where in the World Are My Keys?"
Steve Farnworth of SafeNet talked about "Universal Key Management in an Age of Encryption Fragmentation."
Jon Geater of Thales talked about "Key Management Control Strategies in the Cloud Information System."
Boris Schumperli of Cryptomathic talked about "A New Approach to Key Management in the Cloud."
And to end both the day and the event, Ramon Krikken of the Burton Group led a panel discussion on cloud key management.
Each of the talks had some interesting things to say. The best way to get more detail on what was covered in them is probably to download the presentations from the KMS web site. Some of the presentations are currently available here. The others will probably be available soon.
After the keynote talks, there were other talks on the first day of the 2011 Key Management Summit from which I learned an interesting thing or two. In particular:
Anthony Stieber, who works for, but does not represent a large bank, talked about how it's actually cheaper to keep sensitive data around than to destroy it. That's something that I hadn't heard before, and I'd be interested in hearing more details of that claim in the future.
He also talked about how common it is to use the current time as a seed for a pseudo-random number generator. The output of a PRNG is only as good as the random seed that's used to initialize it, and it's apparently very common for people to use the extremely low entropy current time for this.
Elaine Barker of NIST talked about the move to 112 bits of strength that NIST is now requiring. The people at this meeting were probably the wrong audience for this talk. Everyone there knew about this requirement.
But there are still people out there that don't know about this yet. If you're one of them, read NIST's SP 800-131A, (PDF) "Transitions: Recommendation for Transitioning and Use of Crypographic Algorithms and Key Lengths" as soon as you can.
Ramon Krikken of the Burton Group talked about how people are still worrying about how to encrypt sensitive data and haven't yet tried to solve the harder problem of managing the keys that they'll need to encrypt that data. He also expects that people will be surprised by how hard key management is when they eventually try to do it.
He also talked about how tokenization is actually a form of encryption, despite the marketing spin from tokenization vendors that might try to convince you otherwise. He also talked about how it's probably possible to model the security of tokenization systems using the existing framework that we have for encryption schemes. A tokenization server certainly looks like a random oracle, doesn't it?
He also mentioned how it seems that vendors are calling tokenization "tokenization" instead of "encryption" to convince their customers that by using their technology they will avoid having to comply with the parts of the PCI DSS that require strong key management to support any encryption that's used. It certainly sounded like the PCI SSC people ought to talk to Ramon about this.
Ramon also mentioned how it may end up being the case that so-called silos of key management may not actually end up being a bad idea. If this is true, that may make it much easier for the people working on the KMIP standard. After all, if you really don't need a general key management protocol that works absolutely everywhere, you can just focus your attention on the areas where there's actually a pressing need for an interoperable key management protocol. Like in storage, for example.
Chris Kostick of Ernst & Young talked about you can use your auditors to help you create a sustainable key management program. He recommended that you don't audit encryption, but audit key management instead. He also mentioned that he's often asked how to tell if data is actually encrypted.
If an encryption scheme is IND-CPA secure, for example, then ciphertext is indistinguisable from random bits. Because of this, the very definition of IND-CPA security means that you really can't tell if data is really encrypted because you can't tell if a blob of bits is a ciphertext or just random values. You may be able to look at the format of the data, but just because something is formatted as a PKCS#7 blob doesn't mean that it actually contains ciphertext. Apparently Chris spends a lot of time explaining this to his clients.
Dan Boneh gave the second keynote at the 2011 Key Management Summit. The title of his talk was "Social Keys: New Directions in Public Key Management." If you've never heard a presentation that Boneh gives, you're missing a lot. He seems to cover lots of interesting material, and you feel very smart for a few days afterwards because you're able to amaze and astound people with your deep and profound knowledge of information security. So although Boneh only talked about Social Keys for a few minutes, nobody seemed to mind because the other material was so interesting.
The part that I found the most intereresting was the discussion of man-in-the-middle attacks against https. Although the https protocol was designed to prevent MITM attacks, web browsers don't have a user interface that really lets users know that they're being hit by a MITM attack, which means that it's really not that hard to actually carry one out.
It seems that researchers were curious about how frequent MITM attacks against https really are. After all, if it's feasible to carry them out, we should expect to see hackers doing it. I found the results of the research somewhat surprising. Apparently MITM attacks rarely, if ever, happen on the Internet, but they happen very frequently inside businesses. It's probably the case that the MITM attacks that actually happen are just your corporate IT department doing something for what's probably a good reason, but it also means that you can't expect secure connections to actually be secure if you're doing them from work.
Boneh also talked about some of the problems with validating certificates, particularly with using OCSP. In addition to the practical issues that essentially make it impossible to actually use OCSP, Boneh mentioned how OCSP can actually provide an easy way to bypass the privacy that the supposedly private modes of web browsers give you. This is because web browsers apparently cache OCSP responses, and this cache is available outside of the private browsing mode. So even if you can't tell if someone went to the web site https://www.example.com, you'll be able to see that the browser did an OCSP call to validate the certificate used by example.com, which is close enough for most purposes.
The discussion of Social Keys was fairly straightforward. If you're a user of social media sites, just include a URL to your public key in your public profile on one or more of the sites. It's a clever idea, but I doubt many people will actually use it. But that's because very few people will actually use public keys, so there are very few people who will need a way to get their public key to other people.
The first talk at the recent 2011 Key Management Summit was a keynote by Dorothy Denning, who gave a retrospective of the past 30 years or so of key management. Denning has been working in the field for longer than many cryptographers have been alive, and she's one of very few people who have actually experienced how the field has changed so dramatically over the past few decades.
One of the interesting things that Denning mentioned was how 30 years ago it was possible to keep up on every development in the field of cryptography. There weren't that many papers published on cryptography so it was fairly easy to read and understand them all. And there were only a few conferences that included presentations on cryptography, so it was fairly easy to attend them all.
Today, however, there's so much new material being created that it's impossible to keep track of it all. Even in a very specialized niche like pairing-based cryptography (the technology that Voltage uses in its identity-based encryption, for example), there's so much new material that it's impossible for a single person to read and understand it all. This trend will probably continue, so that cryptographers will probably become very specialized in the future, knowing more and more about less and less.
Denning also had some interesting comments about why there is such a big gap between the interests of commercial cryptographers and academic cryptographers. Part of the gap is apparently due to the fact that it's hard for academics to get funding to work on implementations of technology. Some of the gap is just due to the fact that academics really don't care about practical issues. So we should expect to see academic cryptography advance at a rapid rate in the future, but not expect to see many of its creations actually be useful for much.
Denning also had some good things to say about TriStrata, an encryption technology that John Attala unsuccessfully tried to market back in the dot-com era. This was the first time that I had heard anything positive said about TriStrata, and it was a bit surprising to hear it from Denning. I'm not sure that many commercial cryptograpers would agree with her on this particular point.
Some of our QA people recently came across some unexpected behavior that took them a while to explain. They were testing format-preserving encryption with an Oracle database. They encryped a date, stored it in Oracle, read the encrypted value back out and then decrypted it. When this failed, they started trying to figure out what was going wrong, which took a while.
It seems that the ANSI date is only defined for dates from January 1, 1601 forward. Something like February 12, 1523 isn't a valid ANSI date, for example. But if you use FPE to encrypt a date and you don't define how the format is being preserved carefully enough, it's possible to get a valid date mapped to an invalid date.
It seems that if it's configured a particular way, Oracle doesn't like ANSI dates that are before 1/1/1601 and will automatically change them to 1/1/1601 if they appear. In most cases this works just fine because the vast majority of business data is from the past several decades. But when you FPE-encrypt a date and get an older date, this can actually cause trouble.
Yet another example of why IT is almost always harder than you first think it's going to be.
A couple of weeks ago I noted how a recent report from the (ISC)2 talks about how information security is getting hard and noted how this applies to the entire IT industry, not just to information security. Using IT is definitely getting more and more difficult. Could IT be the ultimate destructive force that clears out older companies and makes way for newer ones, perhaps the "creative destruction" that economist Joseph Schumpeter popularized?
The nasty problems of dealing with complicated, legacy IT environments, after all, is really a problem that older companies have a much more difficult time with than newer ones do. If you start a company today, you can use all sorts of IT that wasn't around 10 years ago, and this can make you much more efficient than a company that's stuck working with 30 or more years of legacy systems.
The problems that governments seem to have with IT may be an example of this in action. They're probably the ones who have some of the most compllicated legacy environments to deal with. And they're also the ones who seem to have the biggest IT problems.
Governments are unlikely to disappear because their IT infrastructure gets too expensive, but that type of problem can definitely kill a business. Maybe we'll actually see this happening in the future as keeping legacy IT environments running ends up costing more and more.
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.
The recent 2011 (ISC)2 Global Information Security Workforce Study has some interesting things to say about working in the industry today. In particular, they note that people in the field tend to be overworked:
Information security professionals are stretched thin, and like a series of small leaks in a dam, the current overstretched workforce may show signs of strain.
This may certainly be true, but I don't think that this is limited to just the information security industry. Modern IT is getting to be a huge headache to support and maintain, and as large systems grow over time they become more and more like the Winchester Mystery House, that San Jose tourist attraction that was built by Sara Winchester from 1884 to 1922 at a cost of roughly $5.5 million.
Apparently, Ms. Winchester was concerned that the ghosts of people killed by Winchester firearms would kill her if she stopped construction of the unusual building. The result of this 38-year project is a 160-room house that's truly bizarre. It has only 17 chimneys for its 47 fireplaces. It has stairs that lead to the ceiling. It has cupboards that open onto brick walls. It even has a door on one of the upper floors that opens onto a drop straight to the ground below. Much of it doesn't make any sense at all. It seems to have built without much planning, and it was fairly expensive. In other words, it's just like today's computer networks. And doing anything with these networks is getting more and more difficult.
Information security is about getting today's networks to work in a secure way. That's hard. But these days it's getting harder and harder to get them to work at all.
 |
|||
|
|||
 |
