Upsilon Payments Payment Security

In addition to providing 256-bit encryption of its website, Upsilon Payments uses Microsoft SQL 2008 to provide protection for its entire database.

Microsoft SQL 2008 uses Transparent data encryption (TDE) and allows encryption on two levels: database level and cell level. Upsilon Payments is only a few websites within the industry which are providing this added security, and this database encryption is above and beyond the PCI and NACHA requirements. If your site currently doesn't provide this protection for your business -- demand it!

For further information read below.

Transparent data encryption (TDE) is a new encryption feature introduced in Microsoft® SQL Server 2008. It is designed to provide protection for the entire database at rest without affecting existing applications. Implementing encryption in a database traditionally involves complex application changes such as modifying table schemas, removing functionality, and significant performance degradations. For example, to use encryption in Microsoft SQL Server 2005, the column data type must be changed to varbinary; ranged and equality searches are not allowed; and the application must call built-ins (or stored procedures or views that automatically use these built-ins) to handle encryption and decryption, all of which slow query performance. These issues are not unique to SQL Server; other database management systems face similar limitations. Custom schemes are often used to resolve equality searches and ranged searches often cannot be used at all. Even basic database elements such as creating an index or using foreign keys often do not work with cell-level or column-level encryption schemes because the use of these features inherently leak information. TDE solves these problems by just encrypting everything. Thus, all data types, keys, indexes, and so on can be used to their full potential without sacrificing security or leaking information on the disk. While cell-level encryption cannot offer these benefits, two Windows® features, Encrypting File System (EFS) and BitLocker Drive Encryption, are often used for the same reasons as TDE—they provide protection on a similar scale and are transparent to the user.

Microsoft SQL Server Encryption

Microsoft SQL Server offers two levels of encryption: database-level and cell-level. Both use the key management hierarchy.

Cryptographic Key Hierarchy

At the root of encryption, a tree is the Windows Data Protection API (DPAPI), which secures the key hierarchy at the machine level and is used to protect the service master key (SMK) for the database server instance. The SMK protects the database master key (DMK), which is stored at the user database level and which in turn protects certificates and asymmetric keys. These, in turn, protect symmetric keys, which protect the data. TDE uses a similar hierarchy down to the certificate. The primary difference is that when you use TDE, the DMK and certificate must be stored in the master database rather than in the user database. A new key, used only for TDE and referred to as the database encryption key (DEK), is created and stored in the user database.

This hierarchy enables the server to automatically open keys and decrypt data in both cell-level and database-level encryption. The important distinction is that when cell-level encryption is used, all keys from the DMK down can be protected by a password instead of by another key. This breaks the decryption chain and forces the user to input a password to access data. In TDE, the entire chain from DPAPI down to the DEK must be maintained so that the server can automatically provide access to files protected by TDE. In both cell-level encryption and TDE, encryption and decryption through these keys is provided by the Windows Cryptographic API (CAPI).

The following figure shows the full encryption hierarchy. The dotted lines represent the encryption hierarchy used by TDE.