Encryption = Less Secure?

Recently in a post to the FMPexperts list a question was asked about securing a database away from the system administrators. The current FMP security model doesn't provide a method for the database owner to secure the system against the database administrator. Someone with physical access to the file has the ability to attack that file at their leisure. While opening an FMP file with a text editor will reveal little, the savvy hacker will soon discover and bypass the encoding scheme used. The less savvy hacker will fork over $45 to provide them with access to the file.

In a thread on another list a question was raised about a safe method for storing credit card numbers and other sensitive information in the database. A method using an encrypted version of the data, such as with the Troi Encryptor Plug-in, would be more secure but only insofar as the key can be protected, and in relation to the value of the data. If the data is valuable enough, say the credit card numbers and PINs for 100,000 customers, a determined hacker will employ a commensurate amount of resources at obtaining the data. As always, Bruce Schneier has provided a sobering report on the reliability of cryptosystems in general when the sophisticated attacker has access to the system.

Use of encryption often leads to a false sense of security. The developer focuses on the encryption of the data rather than understanding the threat vectors and the overall security of the system. This includes the systems on which the application resides as well as those who have access to those systems. The developer will need to do more than "ensure those particular fields are encrypted in the database." As Skeeve Stevens notes in his request in the FMPexperts thread, sometimes the threat agent includes individuals you would prefer be trusted, such as the network administrator.

Jason DeLooze makes the suggestion of a public key cryptography system. Unlike the symmetric AES-128 algorithm in which the key used to encode the data is the same key used to decode the data, PKC uses two keys, a "public" key used to encrypt the data and a "private" key to decrypt the data. The advantages of this system are apparent. Using AES-128, a modern and strong algorithm, the weakness is that the key for encryption needs to be known by the system. That key is either stored in the system itself or supplied each time it is necessary - the former being insecure and the latter error-prone. With PKC only the "public" key used for encrypting the message is known to the system.

This still does not provide us with a fail-safe mechanism for storage of confidential information in the database. An online shopping cart needs to be able to store your credit card number and also retrieve it when you want to make a purchase. As such, using PKC the system would need to know both the encrypting and decrypting keys, making it no more secure than AES-128. Whenever a third party involved in the transaction has access to either the unencrypted data or the key to decrypt the data then there is necessarily an element of trust involved.

It is possible to design a highly secure system using PKI. There are a number of security vendors, including the well known names such as Verisign and Thawte, that will help architect a system that is hardened against both external and internal threats. Of course if the threat agent includes the security designer then you may want to consider another line of work.

Comments

[Steven H. Blackwell]

These points are well taken. The usefulness of any security system is a function both of closing vulnerabilities and of mitigating damages from any breach. But the threat vectors and the risk levels must first be determined. And that is a lot harder than it seems at even third blush when you really get into it.

And that's a good subject for another blog article. Thanks as always to Corn Walker for his sharply penetrating insight.

Steven