Tech Trends: Developments in Cyber Security

Oct. 14, 2015
Block chaining, encryption and more

Cyber security continues to make a major impact on your customers, and today, cyber matters should be on everyone’s mind. A number of interesting items relating to cyber security have crossed my desk over the last several months. Some of the developments below provide immediate benefit, and some will develop over the longer term.

Block Chaining

By now, most of us have read about Bitcoin — the pure digital, non-governmental currency, used by online criminals and legitimate buyers alike. In fact, more than 100,000 merchants now accept Bitcoin, including Microsoft, Dell, Wikipedia, Twitch, Greenpeace, Expedia and PayPal. Whether are not you plan to use Bitcoin, the underlying technology of block chaining is said by many to be more significant than the Bitcoin application itself.

A block chain is actually a database of transactions, appropriately encrypted, that is shared by all nodes in a system. Each transaction in the life of the digital “something” contributes to the database in a way that creates an exact record of the chain of transactions. Every block contains a hash of the previous block to guarantee the chain’s integrity.

Bitcoin uses the technology to achieve distributed consensus on who owns what coins. The term “alternative chain” is used to describe a consensus process for non-financial transactions. A Nov. 2014 article in Computerworld (www.computerworld.com/article/2851414) describes the benefits as: “Any application that requires a system of record — whether banking, property ownership records or election voting — could potentially benefit from a system of decentralized consensus by breaking away from the classic ‘keys to the kingdom’ problem and eliminating any single point of failure.”  

Encryption and Decryption Advances

IEEE Spectrum magazine had a fascinating article entitled, “How to Compute with Data You Can’t See” (http://spectrum.ieee.org/computing/software/how-to-compute-with-data-you-cant-see). Think of it as how you might address encryption vs. big data, where the increasing need to encrypt more data complicates the analysis of that data. The only apparent solution would seem to be decrypting before analysis.

Researchers at MIT, however, have found that certain properties of encryption schemes actually allow the performance of certain kinds of analytics on the encrypted data, where decryption only needs be performed on the final analytical result. This builds on the 1999 work of a French researcher, Pascal Paillier, who devised an encryption scheme with the property that multiplying encrypted numbers yields the encrypted value of their sum.

In 2009, Craig Gentry, a Stanford researcher devised an encryption scheme — homomorphic — that allows a computer to calculate (with some effort) any function on encrypted data. The MIT researchers found that the process could be made more efficient by using different encryption schemes for different types of planned computations.

In 2011, a group of experts developed CryptDB that works by executing SQL database queries over encrypted data using a collection of “efficient SQL-aware encryption schemes.” For more on CryptDB, see https://css.csail.mit.edu/cryptdb.

Google, SAP, and others are now using or building on this research to conduct secure database searches and operations. The ongoing research holds great promise for ultimately encrypting and taking advantage of the massive amounts of stored data without expending corresponding computing resources to do so.

Protecting Databases

Speaking of encryption, Microsoft’s Transparent Data Encryption (TDE) offering is available with their SQL (database) Server (versions 2008 and later) and now on their Azure SQL cloud database service. SQL stands for Structured Query Language and is the de facto language for communicating with relational database systems. TDE protects information within the database by encrypting in real time the data and log files in a way that is transparent to the user.

A symmetric Database Encryption Key (DEK) encrypts the entire database and is itself secured by either a certificate or an asymmetric key, depending on the SQL implementation. There are a number of benefits to this approach. First, the encryption will allow easier and broader compliance with regulations involving the privacy of data. It can safeguard against the compromising of physical security of the media where one could gain direct access to the database file. It may also alleviate the need to otherwise pre-encrypt data going into the database, simplifying data retrieval and eliminating overhead. Applications need not be modified to handle encrypted data, since data encryption and decryption are managed by the database. There is a choice of encryption algorithms, including Triple DES and AES.

Given the continuing movement to cloud-based services, this is very significant. Many services within the security industry — including my own SecuritySpecifiers web service — use SQL, dynamically populating web pages from the database. Also, our SecuriKeep Security Data Management System, currently in field trial, is planned to be offered as both an Azure cloud-based service and on an enterprise SQL server and will offer TDE.

Microsoft is careful to note that this encryption is for data at rest. For data in motion, SSL/TLS (used in https) or a dedicated VPN would be needed to protect data in transit between networks, and appropriate security procedures should be observed to protecting data within a network.

Further, Microsoft publishes these general encryption principles:

  • Strong encryption generally consumes more CPU resources than weak encryption.
  • Long keys generally yield stronger encryption than short keys.
  • Asymmetric encryption is weaker than symmetric encryption using the same key length, but it is relatively slow.
  • Block ciphers with long keys are stronger than stream ciphers.
  • Long, complex passwords are stronger than short passwords.
  • If you are encrypting lots of data, you should encrypt the data using a symmetric key, and encrypt the symmetric key with an asymmetric key.
  • Encrypted data cannot be compressed, but compressed data can be encrypted. If you use compression, you should compress data before encrypting it.

For more on Microsoft SQL encryption, refer to https://msdn.microsoft.com/en-us/library/ms189586.aspx.

Ray Coulombe is Founder and Managing Director of SecuritySpecifiers.com and RepsForSecurity.com. He can be reached at [email protected], through LinkedIn at www.linkedin.com/in/raycoulombe or followed on Twitter, @RayCoulombe.