eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Encryption isnt a fairy dust that developers can sprinkle over work that was done without application-level security in mind. Its not even a single attribute that can be added in varying degrees that trade off strength against performance. Different domains call for differing definitions of what kind of security is relevant, as well as what modes of security are feasible.
England-based nCipher, founded 10 years ago by brothers Nicko and Alex van Someren, has made its mark by wrapping enterprise-class infrastructure around the kernel of potential protection provided by strong encryption algorithms.
Company Marketing Vice President Richard Moulds and Data Encryption Product Manager Jeff Montgomery, both in Stoneham, Mass., spoke with eWeeks Peter Coffee about the need for developers to go beyond questions of algorithm choice and key length to make their application portfolios end-to-end secure.
It seems that application developers need a growing knowledge of data protection from the point of data entry through intermediate storage and during all interactions with users. What does the developer need to know about the role and the structure of crypto technology?
Montgomery: One of the first things that developers need to get their heads around is the threat model that theyre trying to protect against. Any organization thats implementing encryption has to have a clear understanding of what that is. It might be dictated by a compliance issue or regulation, or by their own policies. Does the enterprise only care about people stealing tapes? Or about access to points in the application stack?
Once they have a clear understanding of what that threat model is, they can begin to look at the types of integration strategies that they have to put in place; once they start looking at integration strategies, theyll need to look at the different technologies that are in place at different points in the stack.
From a technology standpoint, what types of approaches do they have to take? Thats going to depend on whether its a homegrown app or a packaged app. It might be a packaged app for which they have some access to the code, [or] for which there are well-defined entry and exit points.
Ultimately, it comes back to the level of security theyre looking for: What are they doing with the data? Whats the level of granularity? Whats the level of security they have to provide?
Its important to make sure that administrative accounts dont have all access to data: separating out the traditional file or database admin roles, pulling out the security admin role from that, putting a piece in place so there isnt any one superuser.
Is that something that platforms facilitate better today, compared with 10 or 20 years ago when pretty much by definition there was a “god user”?
Montgomery: There still is a “god user.” I think the database vendors and packaged application vendors are starting to think about it. Theres an inherent issue in that these things are architected with these superusers. You have to change the administrative model. The only way to truly achieve [privilege] separation is to have a management process outside the scope of the application, which means you have to build into the application entry and exit points—where the application can make a request for, say, an encryption key thats managed by someone else.
We are seeing that. I know that SAP has put some hooks in there to try to facilitate that kind of thing. A lot of the homegrown apps that people have written dont have that in there, but people are going back in to retrofit that type of process.
Despite the best efforts of the largest application vendors, people still have a myriad of different business apps that theyre running in their environment. If you separate out the administration of keys and that separation of duties, you create a need for a management application to make sure that security policies are uniformly enforced across all the different applications that might access sensitive data.
Next Page: Rolling your own management system can create a mess.
Rolling your own management
system can create a mess”>
Instead of needing just one trustworthy superuser, do you wind up with points of vulnerability because youre rolling your own management system for applications that all do it differently?
Montgomery: At a minimum, that can create a management challenge. Within a specific application, some of the concerns that you have to look at are, What are you doing with the data? Is it going to be heavily searched upon? Is it part of search criteria? Or will it only ever be displayed as part of a record on the screen? That will drive the type of technology and the type of coding that youll put around the encryption.
Think about how your application will behave if you scramble the data. You may have to [insert] some logic that searches on the ciphertext, which means you have to select the right encryption mode to support that type of capability. Those are the types of things that application developers have to think about. And oh, by the way—you have to retrofit that into an application in many cases [whose designer] never thought about that kind of stuff.
Is it common for developers to make bad choices that do things correctly, but with unacceptable impacts on performance?
Montgomery: Absolutely. If you encrypt a piece of data, [and] you dont process it properly, you can force things like table scans on databases. Your application can even give you erroneous results when it cant find records that it should be able to find.
Are there any common pitfalls that people encounter when they try to graft encryption into an IT stack that wasnt designed with that in mind? Do they wind up with the form of security but not the substance?
Montgomery: Someone might roll their own [solution] and find out that its not compliant. [That might be] their own system or a system from their own application vendor that tries to solve the vendors problem but not within the context of compliance.
Is there a broad lack of understanding of what encryption really is? Do legislators, for example, understand there are degrees of protection, with some encryption approaches vastly less effective than others?
Moulds: Encrypting data is easy; looking after the keys is hard. And if you leave the keys hanging around, it doesnt really matter what algorithms you use—its all been a bit of a waste of time.
As Microsoft talks about the use of [Trusted Platform Module] chips in Vista, I think that will start to shift peoples minds toward the idea that crypto has to be done in a different way—that there is good crypto and bad crypto, strongly implemented and poorly implemented crypto. The idea that keys have to be looked after in hardware hasnt broadly permeated outside the sectors of banking or server management. As people start marketing PCs with that kind of capability, the depth of secrecy will be seen as directly impacting security.
Montgomery: One thing I can tell you were seeing is that industry initiatives, like [Payment Card Industry]—even if not as specific as they could be—are opening doors. People are saying, “If we have to do it anyway, lets do it right.” The technology they put in place has to be flexible enough to handle the things theyll eventually want to do.
And [we talk to developers] about the quality, not only of the crypto, but also of the key management and key recovery across a portfolio of applications. And when information is archived across 10 or 20 years, how can a developer be sure that an administrator will know which application encrypted something, using what keys?
A lot of developers are trying to embed encryption deeply in the internals of an application, because thats the way to make it really efficient. The application knows how the data is used. But questions of key management have to be addressed outside the application.