Here’s a simple example. Suppose that a file system replicates data across two storage devices to prevent data loss in the advent of a drive crash. If these storage devices are virtual, they can well reside on the same physical hard drive. One physical drive crash, then, will wipe out the file system.

A drawback of fluid logical-to-physical resource mapping is uncertainty it creates about the physical configuration, location, and administration of underlying hardware. Virtualization amplifies software risks too, such as accidental or malicious state rollbacks.

RSA Labs has a long-term research program that aims to restore to both service providers and tenants the security visibility concealed by virtualization and cloud migration. A key element is an idea we call a security inlay, a module transparently introduced into virtualization infrastructure with hooks that make it easier to monitor systems’ security postures. Good inlays, we believe, can actually provide better visibility than even a traditional data center affords.

The Iris system, for example, can serve attractively as a security inlay to render virtualized storage more trustworthy.  Iris ensures the freshness and integrity of data retrieved from storage—any kind of storage in any location. If a corruption or rollback affects retrieved data, Iris will detect it. Iris is also the first system that enables practical, dynamic Proofs of Retrievability (PoRs). It can verify on the fly that all of the data in a file system is intact—down to the last bit. Magically, this operation in Iris touches only a small fraction of the contents of the file system.

One deployment option for Iris is as a security inlay. A tenant’s applications in a VM can, using Iris, detect corruption of retrieved data blocks; Iris is transparent, moreover, to the OS in the VM. At the same time, the tenant can remotely verify the intactness of the file system on demand. In this configuration, Iris brings two benefits: (1) It incorporates potentially untrustworthy storage into the trust perimeter of a tenant’s VMs and (2) It offers a new path or tool for monitoring file system state, and thus auditing compliance with data-retention requirements and regulations. (Note that Iris doesn’t do anything to improve availability or prevent failures: Other inlays or complementary mechanisms are needed to address these complementary issues.)

Here’s a figure illustrating this deployment of Iris.

You can learn more about Iris from our research paper here. The paper won an award a couple of months ago, incidentally, thanks to the excellent work of its lead author, Emil Stefanov, a student at UC Berkeley who worked on Iris during a summer internship at RSA Labs.

• 

In computing environments, researchers have demonstrated a rich array side-channel attacks that completely compromise secret cryptographic keys. (Perhaps the most bizarre is Shamir and Tromer’s use of CPU acoustics to extract keys.) So it’s important to ask: Could side-channel attacks permit malicious tenants to steal secrets from others in the cloud?

Virtualized environments might appear at first glance to dampen or expunge side-channels through strong isolation, one of their design goals. VMs run in distinct operating system instances isolated by a hypervisor and may even migrate across CPU cores. Many systems, in fact, rely implicitly on the security properties enforced by VM isolation. In a public cloud, a motley array of tenants, benign and malicious, are secured against one another mainly through virtualization.

But it turns out that virtualization doesn’t equal effective isolation. This past week, at ACM CCS, a major security research conference, lead author Yinqian Zhang presented a joint paper (UNC, Univ. of Wisc., and RSA Labs) documenting the first significant cross-VM side-channel attack. This attack leverages the L1 instruction-cache as a side channel. We explored the attack in the lab on a Xen-based virtualization platform representative of public cloud infrastructures. In our experiments, an attacker VM targets a co-resident victim VM running Gnu Privacy Guard (GnuPG), a software package that incorporates the OpenPGP e-mail encryption standard. The attacker VM is able to steal the victim VM’s full private (ElGamal) key. In other words, the attack results in complete compromise of one form of encryption in GnuPG.

As demonstrated, the attack is fairly narrow: It targets one vulnerable application in a particular class of virtualized environment. (GnuPG relies on a cryptographic package called libgcrypt that lacks well-established side-channel countermeasures.) It’s also fairly involved, requiring heavyweight use of machine learning, among other things. For various reasons, technical and ethical, we did not execute the attack in a public cloud. That said, the general techniques we’ve demonstrated are certainly extensible to other virtualization environments, applications, and forms of sensitive information. There’s no reason to think that a public cloud or any other virtualized environment is immune.

The takeaway is this: VMs running highly sensitive workloads should not be placed on the same hosts as potentially untrustworthy VMs.

Here’s a link to the paper.

Citation: Cross-VM Side Channels and Their Use to Extract Private Keys. Y. Zhang, A. Juels, M. K. Reiter, and T. Ristenpart. ACM Conference on Computer and Communications Security (CCS), pp. 305-316. 2012.

• 

Resources in public clouds are sold on the same premise of uniform quality as apples. A virtual machine (VM) of a given type, for instance, is a fixed-sized bundle of resources—CPU, local storage, and so forth—that is rented to a tenant at a set hourly rate. Yet VMs, like apples, vary in quality. A VM’s performance depends on the CPU model in the machine on which it sits, the workloads of its neighbors (the VMs of other tenants), and a variety of other characteristics.

Is it possible, then, for a savvy shopper in a public cloud to throw bad fruit back into the bin? In other words, does careful selection enable a clever tenant to get higher-performing VMs for a given amount of money? The answer is yes.

In a paper recently presented at the Symposium on Cloud Computing (SOCC), academic colleagues at Univ. of Wisconsin together with RSA Labs have shown that it’s possible for a tenant to game public clouds to achieve better VM performance. Public clouds don’t allow tenants to select VMs freely like apples in a supermarket. But tenants can periodically shut down under performing VMs and spin up new ones. In our experiments in a public cloud, exploiting this small degree of control yields performance gains of 5% for CPU-bound jobs and 34% for bandwidth-intensive jobs.

Essentially any public cloud with a simple pricing regime is likely to be vulnerable to such gaming by tenants. A natural follow-up question is what happens if  cherrypicking by tenants becomes standard practice. The answer may be like the one at the supermarket: Avoid shopping for picked-over VMs on a Sunday evening.

The paper ((c) ACM) is here: “More for Your Money: Exploiting Performance Heterogeneity in Public Clouds“

• 

So this grandfather of the mobile phone, one of today’s most fetishized, life-altering technologies, waited decades to realize its full potential. It took about 75 years for the first handheld mobile phones to be widely deployed. Such is innovation: The art of liberating vintage technology from the confines of its era.

Today, RSA is pleased to announce the release of Distributed Credential Protection (DCP). DCP offers the industry a transformative approach to one of its most pressing security problems: Massive breaches of sensitive information, such as password databases. DCP distributes secrets across two servers or even two organizations and periodically rotates them through re-randomization. An attacker that breaches one server, or even both of them at different times, learns nothing.

In this case, it took only a bit more than 20 years for a powerful idea to see the light of day.

In 1991, Rafi Ostrovsky and Moti Yung published a landmark paper on what would come to be known as “proactive cryptography.” Their idea was that servers might be breached, not just once and in isolation, but by “mobile” adversaries that attack a broad array of targets repeatedly. They proposed a defensive technique in which secrets are distributed across servers and regularly re-randomized.

In 1991, the Internet was in its infancy. Breaches were nearly unheard of. Mobile adversaries? Why should I worry about servers being regularly breached when remote attacks rarely happen to begin with, thank you? Recent password breaches at LinkedIn, etc., etc., were just twinkles in Rafi and Moti’s eyes. (Today it’s: Why worry about breaches when I can just hash my passwords, thank you?)

DCP realizes proactive cryptography in the limited setting of two servers—and may be extended in future versions to more (m out of n). Of course, just as mobile phones today include a lot more technology than Stubblefield’s demonstration device, and much more user-friendly packaging, DCP is an advance on its 1991 ancestor in print. It realizes ideas due to many researchers before and after Ostrovsky and Yung; at its heart are inventions from RSA Labs (e.g., this paper and follow-up), and excellent work by RSA Engineering to address the many practical problems of commercial systems.

Admittedly, it doesn’t yet have a touchscreen or run games. But I’m sure those features are on the way.

• 

Still, the team that factored RSA-768 has served the technical community with an important, tangible warning. The U.S. National Institute of Standards and Technology (NIST) published RSA key-length recommendations in 2007 that advise the phasing out of 1024-bit RSA keys by the end of 2010. The factoring of RSA-768 affirms the prudence of this recommendation. Using the best current approach (the Number Field Sieve), successful attack against 1024-bit RSA requires roughly one thousand times the resources required to factor 768-bit RSA. RSA-1024 could well fall to a public effort in the next decade or so. A well-resourced government organization could knock down 1024-bit keys rather sooner. Keys often linger for many years, so now is the time to start retiring 1024-bit RSA in favor of larger RSA key sizes (the standard next step up is 2048-bit).

RSA-768 formed part of the RSA Factoring Challenge, created in 1991 and updated with new challenge numbers in 2001. The Challenge comprised a sequence of RSA moduli of increasing length and difficulty, with cash prizes for successful factoring. RSA Laboratories created the Challenge to stimulate new research into factoring methods and better inform the technical community’s key-length recommendations.

In 2007, RSA Laboratories chose to discontinue the RSA Factoring Challenge. The Challenge was no longer generating new knowledge. Factoring research had matured. Challenge numbers were toppling over the years at a predictable pace.

The factoring of RSA-768 is a case in point. In 2004, Arjen Lenstra (a participant in the RSA-768 factorization) offered a framework for forecasting the computational effort required to factor RSA keys. His work suggested that the computational effort for a 768-bit RSA modulus would be roughly equivalent to that of breaking a 67-bit or 68-bit symmetric key—about 2⁶⁷ computational steps. The Kleinjung et al. paper reports a computational effort of… about 2⁶⁷ operations. (A “step” and “operation” here aren’t interchangeable, but are loosely comparable.)

The Kleinjung et al. paper carries another unmistakable sign of the maturity of factoring research. It’s the first I can recall on the topic that gives the nod to project management. “We… note that larger efforts of this sort would benefit from full-time professional supervision.”

Of course, cryptology is not immune to surprises. An innovation in factoring algorithms or custom factoring hardware or a rapid advance in quantum computing could shake predictions. But amid the eddying pool of uncertainty that is computer security, NIST’s carefully crafted guidelines on RSA key lengths will probably serve as an anchor for many years to come.

[1] Kleinjung et al., Factorization of a 768-bit RSA modulus, v 1.0. IACR ePrint archive. 7 January 2010.
[2] Arjen K. Lenstra, "Key Lengths", Handbook of Information Security. 2004.
[3] NIST Special Publication 800-57 Part 1, Recommendation for Key Management, Special Publication 800-57 Part 1, NIST, 03/2007.
[4] The RSA Factoring Challenge. RSA Laboratories. 1991-.

• 

RSA is the mainspring of the novel: A group of Pythagoreans, followers of the ancient mathematician Pythagoras, appear to have broken the RSA algorithm. Pythagoras is of course the man credited with the Pythagorean Theorem. But he was also a cult leader, inspirer of many utopias, possible coiner of the term “philosophy” and much else besides. My novel Tetraktys (named after a Pythagorean mystical symbol) is about the NSA’s effort to locate the Pythagoreans before they exploit their power in cyberspace toward a slowly gathering, dusky purpose.

The RSA Conference, with its thousands of attendees, is an emblem of the many layers and complexities of computer security today. Amid the jostle of people and products, it’s easy to forget that the bedrock is cryptography—encryption and digital signatures. And even when we do think about cryptography, it’s easy to forget the rich heritage, a golden thread of intellectual achievement that spans centuries and touches such far-flung fields as music, astronomy, and political science.

I wrote Tetraktys in part to capture the marvel and adventure, the abstract puzzles and strange stories that make our industry so interesting. If you read it, I hope that Tetraktys will serve as a reminder of these things. Perhaps you’ll approach your own job with a fresh glint in your eye.

• 

Barcode-type RFID tags contain codes that can precisely identify consumer items. (E.g., “This is a 100-count bottle of 45mg Oxycontin® tablets.”) Such tags can therefore betray private information about consumers to nearby RFID readers. Barcode-type RFID isn’t often on store shelves yet, but may well be soon. Consequently, some in the RFID industry say:

(1) “I want RFID tags that are readable by all of my commercial partners in the supply chain, but…”
(2) “I don’t want the item codes to be readable once tags reach consumer’s hands.”

Many RFID tags respond to a “kill” command–a self-destruct feature for privacy protection that’s enabled by a tag-specific password. The two requirements above are achievable if tags are “killed” at the point of sale. But the RFID industry request includes two more requirements:

(3) “I don’t want to manage any keys, e.g., kill passwords.” (Tags cross geographies and organizations in tortuous ways that thwart good key management.)
(4) “I don’t want to require any special physical process to protect tags.”

A tall order indeed! And to top it off, the industry is already wedded to an RFID standard tag called EPC (Electronic Product Code) whose technical specifications are largely fixed (and austere).

RSA Labs and ThingMagic LLC have devised what we see as a practical solution to this tricky problem–and similarly to the problem of managing keys for tag authentication.
Bryan Parno, an RSA Labs summer intern from Carnegie Mellon University, will be presenting the solution at USENIX Security ’08 next week.

The basic idea is simple: We propose storing RFID tags’ keys on the tags themselves. It’s also counterintuitive: After all, how can keys be used to secure the very devices in which they’re stored?

For the answer, have a look at our research paper…

• 

So what pieces of conventional wisdom in computer security are like margarine and the 8×8 water doctrine? I’d hold forth password expiration as a prime candidate.

It’s common for IT administrators to require users to change their passwords every few months. (Ninety days is a typical period.) This policy narrows the window of opportunity for an attacker to guess or uncover a user’s password. What are the vectors for password discovery, though? Hashed password tables are subject to brute-force attack, but there are tools that can successfully crack a Windows password in a matter of seconds, not months. Passwords written on crib sheets are also a point of vulnerability. But will an attacker really typically wait ninety days to exploit a successful run at a Post-It note?

At the same time, password expiration is a sower of ill will. It causes users to regard computer security mainly as a nuisance. The practice also creates vulnerabilities. One of these is a heavy reliance on password reset.

Password changes often cause users to forget their passwords or become locked out of their accounts. To recover lost or forgotten passwords, users are commonly asked to answer “challenge questions” such as, “What was the name of your first pet?” These questions are none too challenging. They rank among the weakest of passwords. Help desk calls are an alternative. They are expensive, though. And how often do help desk staff challenge you to prove that you are who you claim to be? Or ask you for information available in public records, like your birth date? Abolition of password expiration wouldn’t eliminate the need for password reset, of course, but might allow more attention to be paid in securing it.

It’s easy for me to carp, though. I’m not an IT administrator. In the interest of learning what others think, here’s a poll.

Comments

Password Expiration
Password expiration really is another tenant of IT Security that seems to do as much harm as good when it comes to end-users. It is cumbersome, distracting, and annoying to everyone involved. At the same time, you need to consider that some systems really do need password expirations.

For critical systems password expiration makes great sense. All too often a company will fire an employee but neglect to change the passwords to the VPN, firewalls, routers, file servers, etc. Even if they are supposed to change these per the security policies, these steps can easily be overlooked.

Having a password expiration can help ensure those users (terminated employees for example) will be locked out in due time. That is of course unless they log in prior to expiration and leave in a back-door (such as a dummy user account with full system access).

Bottom line is password expiration can be helpful if done on critical systems and as part of an overall security program. Pretty much like everything else related to security.

www.mbridge.com
- mbridge

What do you think are the likely origins of password expiration, both the practice itself and the standard expiration periods?

Here are some of the responses we got on our poll above…

1. The biggest advantage of password expiration that I can see is that if the password does get compromised you’re limiting the time it can be used for. There’s some really neat technology around that gives you a new password every minute – perhaps you should look at that

2. Before the advent of rainbow tables you’d have to protect against slower computers’ brute force attacks. The belief was that a suitably complex password would withstand attack for some number of months. Look at the Gold ID feature in SOM. The heritage is the old “password crack” program. In 1993 or so, we’d run it on our NIS databases at GTE and find that it couldn’t brute force non-dictionary words too quickly and thus the assumption was that it would take days/weeks/months to crack a particular password. This is no longer true of course. -Rob Polansky

3. I know when it started — just about when it got easy to network PCs. The logic is that changing the password on the account at least slows the crackers down — that if they had your password and owned your accounts, that would change when you changed the password. The cracker would have to start again. Clearly, with keyloggers as a primary attack, changing your password hourly really isn’t going to inconvenience an attacker. However, with legacy systems still in place as the backend for the vast majority of financial and other high-volume, high-sensitivity systems, changing passwords frequently is still useful. On those systems, web-based or Wintel-based attacks are not the primary concern. Forcing password changes can help identify improperly set up processes and unauthorized access. Having desktop users in an enterprise environment change passwords regularly does cost time and annoyance. However, there are internal, low-tech attacks and misuse that can be spotted with frequent password changes. Ninety days is a little long these days — my current employer requires fewer than 60. Super users are generally 14 to 30 days, depending on the sensitivity of the system. Fob-based randomly generated passwords are simply password expiration schemes with the time between required changes extremely short.

4. It seems quite arbitrary to me. Rather like some of the other ‘security tools’ out there, it might have more to do with making users _feel_ that they are secure…

5. Folklore

6. Its done to limit the amount of risk that you might have through someone else knowing your password – but what it really does is make people choose passwords that are easy to remember and sequential – which once you know the sequence means you have access forever. Its really dumb

7. People tend to have the same password for multiple accounts, so forcing people to change their password reduces the likelihood that a shared password that was cracked on the user’s home computer has now made the company vulnerable.

8. misguided auditors

9. I guess the origin might be that when a password gets known to others they can only use it for a specific time so damage is only done a limited time.

10. Misinformed IT administrators who think that forcing password changes will somehow make the system more secure.

11. Ultimatly, passwords exist to protect the organisation’s data not the user. To that end passwords were created and set to expire to protect the organisation from data loss with little or no regard to user experience. I have seen customers attempt to apply an expiration policy to smartcards… which in itself is odd considering they see the concept of expiring their SecurID PIN codes as completely alien. A user that is forced to change their password regularly WILL employ poor practicies to recall them, either by writing them down or attempting to make them the same, or worse the same as their gmail account!

12. Password = passport Passports have expiration dates as do most other “real life” credentials.

13. Medieval Times. People changing passwords to enter a castle. That’s just a fun guess.

14. Anytime someone needed to control access to a location they may have used a password. So you need to look back at the earliest times when people had locations they wanted to secure, AND had the ability to speak. Then you would need to consider when man, or woman, was smart enough to think about changing that password in order to add a layer of security. I would recommend talking with someone at a Natural History Museum for the time when this may have occurred. One guess… 250,000 years ago (start of the Home Sapiens). www.MBridge.com
- Reader Poll Responses

• 

I’m getting married this summer and my family will be traveling to the wedding. In order to make the trip, my parents recently renewed their passports. Not because I’m getting married at an exotic destination, but because they live in Montana and have to fly to the wedding. Like several other states, Montana has refused to comply with the requirements of the REAL ID Act of 2005. The Department of Homeland Security (DHS) had threatened to prevent residents from those states from using their state-issued driver’s licenses as identification at airport security, effective May 11th.

As it happens, the DHS recently granted all states an extension to the May 11th deadline, allowing them additional time to become REAL ID compliant. As a result, driver’s licenses will continue to be accepted as valid identification to board a plane and enter federal buildings until December 31, 2009. Although REAL ID was designed to improve the security of driver’s licenses, several states, including Montana, have drafted legislation prohibiting the implementation of REAL ID.

There are several reasons why states are upset about REAL ID, the first being the lack of funding provided to implement a very costly change. It is estimated that implementing REAL ID will require $11 billion over the next five years, while the federal government has only promised $90 million to assist in the effort. Additionally, many states feel the government is overstepping its bounds by mandating a minimum set of requirements for state-issued IDs. There are also several security concerns being raised about the license requirements.

One such concern is that REAL ID effectively creates a national database of personal information, including full legal names, dates of birth, places of residence and digital photographs. While REAL ID does not create a centralized database of all this information under the control of the federal government, it does require states to tie their databases together, essentially creating a distributed national database. This is being mandated in an effort to prevent individuals from obtaining multiple licenses from different states and also to facilitate the authentication of documents (such as birth certificates) issued by external states. Unfortunately, as a result, any DMV worker in any state will have access to your personal information.

Another concern with the new IDs is a requirement for a common machine-readable technology. The initial implementation will be a standardized barcode without the use of encryption. DHS argues that encryption key management would be extremely difficult and that the need for immediate access to information stored on the card by law enforcement outweighs the potential privacy concerns. Unfortunately, if the information is stored unencrypted, there is nothing to prevent your personal information from being read and stored by anyone who asks to see your license. This includes staff in bars and restaurants — and any place that requires proof of identity or age to enter.

Many state-issued IDs already have barcodes on them, but several states do not. The requirement for a barcode as well as its standardization across states will make ID scanning easier and prompt more businesses to do so. While this may result in a decrease in underage drinking, for example, it will likely also cause an increase in identity theft. As the number of businesses that scan IDs increases, so will the probability that one of them will sell or misuse the information they gather. Even if the states are able to secure their shared databases of personal information, what guarantees are there that businesses will do the same?

Of further concern is the fact that barcodes may be replaced by RFID chips in future versions of REAL IDs. Several border states are creating Enhanced Driver’s Licenses that incorporate RFID in compliance with the Western Hemisphere Travel Initiative, an issue that has already been discussed in this blog entry. The desire to merge these two forms of ID will create a strong push for RFID to be the common machine-readable technology of the future REAL ID.

As you might expect, several groups are opposed to the law, including the American Civil Liberties Union, the American Association of Motor Vehicle Administrators, the National Council of State Legislatures and the National Governors Association. Currently, 18 states have proposed legislation preventing the implementation of REAL ID with laws having already been passed in Maine and Idaho. Many argue that REAL ID would not have prevented 9/11 (the hijackers were all legal residents with proper identification), and will — at best — prevent illegal aliens from obtaining a driver’s license while costing legitimate residents both time and money to get their (mandatory) replacement license.

Thankfully, the DHS extension has relieved immediate travel concerns. REAL ID will now not be enforced until after the November elections and a new administration takes office. With any luck the newly-elected administration will bring with them a better understanding of both national security and personal privacy, and REAL ID will be repealed before it becomes a real issue. If not, we might all have to get passports to fly in our own country.

•