Data Security (File, Database, XML)

Team Essay

Data Security (File, Database, XML)

Submitted by:

Team Name: SecurityGurus

Team Members

Suresh Konda

Jiji Nair

Pallavi Shetty

File Encryption

What is File Encryption? File encryption deals with encryption and decryption of a file, so that sensitive information present in a file can be protected from unauthorized viewing, including the root user or a hacker who gained root privileges.

File Encryption can be achieved using any of the following mechanisms: Disk Encryption, Volume Encryptors, File Encryptors, and File System Encryptors.

Disk Encryption: In this method, the Disk Driver encrypts and decrypts the data stored on the disk. At initialization time, key is provided to the disk driver. Applications and users are transparent to this process. This does not provide individual fine grained access control.

Volume Encryptor: This is similar to the Disk Encryption, except the encryption and decryption is happening at operating system’s device driver level.

File Encryptors: This works at the application layer to provide true end to end file encryption, but applications has to be aware of this. Encryption keys are managed by the user and not the system. PGP tools fall under this category. This is not a scalable solution, but acceptable for few files.

File System Encryptors: In this, file system takes care of transparent encryption and decryption, key management. Encryption can occur at file level or directory level. CFS (cryptographic file system for UNIX), TCFS for UNIX and BSD, and EFS for Windows XP and 2000, fall under this category. This is of much use and interest to us. We will be covering UNIX CryptFS and windows EFS in this.

CryptFS: This is a kernel resident file system, which sits on top of other file systems like NFS, UFS, etc.; uses Blowfish in CBC mode. Applications need not be change as result of this. This is implemented using UNIX V_node stacking facilities, which allows file system functions to be modularized. Keys are managed by the users. User keys would be associated with not only user id, but also session id, making it harder for a hacker to gain access to the file system. Since session id is inherited by children, spanned processes also gain transparent access to the encrypted files. This design decouples file ownership from key possession. File sharing is achieved by sharing of the key. This design is not much scalable from number of files encrypted, different keys, number of users sharing the files. Application at a time can use only one key, to access different files that are encrypted with different keys; application has to change the key in the middle. This is even more trouble some in multi threaded applications. This is suitable in places where there are few files to be encrypted and all using the same key.

Windows EFS:

Windows EFS is implemented based on a combination of public and private key encryption. Random private key is generated per user, per file is used as symmetric key for file encryption and decryption. The key is encrypted with public key for storage. User private key is required to decrypt the key file to get the file key. EFS use the services of AD (active directory) for retrieval of user’s public and private keys. User file key is also encrypted with windows domain’s public key, so that domain admin can recover the files in case of loss of user’s private key. Encrypted file can be shared by multiple users; directory level sharing is not supported. This design is very scalable from number of encrypted files and number of users sharing a given file.

Data Security in Databases

Modern databases contain/store very sensitive information like Social Security Number, credit card number, medical records-history, etc. The need to protect sensitive information from un-authorized access is tremendous. Some legal regulations like HIPPA are aimed at this. Authentication, Access Control, Logging and Auditing, and Encryption of data are the main components of achieving this. In this we concentrate on encryption part. Modern databases like Oracle, DB2 provide table, column level encryption and decryption support.

DB2: IBM’s DB2 database supports functions like ENCRYPT, DECRYPT, DECRYPT_BIN, and GETHINT to encrypt and decrypt column data in a database table. Encryption key is Pass phrase based and the key is managed by the user. If key is lost, it can be recovered by using Pass phrase recovery mechanism. The password/pass-phrase can be specified in the SQL statements or can be set globally using the following command “Set encryption password = `password`”

ORACLE:DBMS_CRYPTO package(10g onwards) supports ENCRYPT and DECRYPT functions with options for selecting various encryption algorithms and key length. Encryption key can be stored with application or as another column in the database. In general, it’s a good idea to split the encryption components (key and function) onto two separate servers to increase the security, intruder has to break into two servers to decrypt or get to the sensitive information. The developed code can be encrypted as well, so even a DBA cannot see exactly how the security is implemented. Wrap, Oracle-supplied utility can be used to encrypt the code.

IBM’s DB2 and Oracle databases differ a lot in authentication, access control, and other aspects of the security. IBM supports there features through integration with Tivoli, where are in Oracle these functions are embedded in within their database product.

XML and data security

A variety of techniques have been developed to allow the interchange of data on the World Wide Web. Currently, XML is considered to be the primary standard for interchanging data among various types of databases and web pages. The three technologies that relate to XML security are XML Digital Signature, XML Encryption and XKMS.

XML Digital Signature

XML Digital Signatures can be used to provide integrity, message authentication and signer authentication for all kinds of data. This technology got W3C Recommendation status on 12 February 2002. Web services use XML signatures to sign SOAP messages and XML encryption to encrypt them.

The basic syntax of a XML Signature is as follows:

<Signature Id="MySignature"

xmlns="

<SignedInfo>

<CanonicalizationMethod

Algorithm="

<SignatureMethod

Algorithm="

<Reference

URI="

</Transforms>

<DigestMethod Algorithm="

<DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>

</Reference>

</SignedInfo>

<SignatureValue>MC0CFFrVLtRlk=... </SignatureValue>

<KeyInfo>

</DSAKeyValue>

</KeyValue>

</KeyInfo>

</Signature>

SignedInfo element contains all the information about what is signed and how it was signed. The signature algorithm is applied to this element to generate the signature.

Although the algorithm used in calculating the SignatureValue is included in the SignedInfo element, the SignatureValue element is outside SignedInfo.

XML Signature provides for enveloped and enveloping signatures. A signature is known as enveloping if the <Signature> element is the parent of the element to be signed. An enveloped signature has the <Signature> element as a child to the element being signed. Any arbitrary octet stream can be signed using XML Signature. First, the octet stream is encoded using Base-64 encoding to form printable data and then transforms can be done on this data to get digital signature. The URI attribute in the <Reference> element can be used to specify the location of the document to be signed. A signature is known as detached signatures when a specific element in an XML document needs to be signed. XPath expressions are used to access elements not within the document element.

A signer can include any key information using <ds: KeyInfo> element. This element is used to specify one or more of the following: the key, a key name, X.509 certificate, a PGP key identifier, etc. or else we can use a link to specify where the complete <ds:KeyInfo> element information can be found. An X509 certificate can be included as shown below:

<KeyInfo>

<X509Certificate>MIIcdfg…..

……………………..

</X509Certificate>

</X509Data>

</KeyInfo>

XML Signatures involve a method known as canonicalization. Canonicalization creates a normalized form of a document. In a transaction, the sender creates and signs a canonicalized form of a document, then sends both the document and the signed form. The receiver performs canonicalization on the document and compares the results to the signed form.

Verification of the digital signature, also known as core validation, is done by two steps: validation of signature over SignedInfo and validation of each Reference digest within SignedInfo. For most XML parsing applications, the signed XML document should be well formed in order to properly process and validate the document. An application might consider a signature as invalid if some part of the core validation fails.

XML Encryption

XML Encryption is a protocol for encrypting data into XML documents. It is an alternative mechanism to provide security requirements that are not provided by SSL. XML Encryption can handle both XML and non-XML (e.g. binary) data. XML encryption can be used in applications that require a combination of secure and insecure communication. XML Encryption follows the traditional PKI encryption steps for public key cryptography. First, the data is encrypted using a randomly created secret key. Then the secret key is encrypted using the recipient's public key. This information is packaged such that only the intended recipient can retrieve the key and decrypt the data. Decryption involves applying the private key to decrypt the secret key and then using the secret key for decrypting the data.

The basic syntax of an encrypted XML document is as below:

<?xml version= “1.0”?>

<Encryption Method/>?

<ds:KeyInfo>

<EncryptedKey>?

<Agreement Method>?

<ds:KeyName>?

<ds:RetrievalMethods>?

<ds:*>?

</ds:KeyInfo>?

<CipherValue>?

<CipherReference URI?>?

</CipherData>

<EncryptedProperties/>?

</EncryptedData>

The XML namespace (xmlns) and type to encrypt any arbitrary data are given below. The encrypted data is placed within the CipherValue tags. The complete CipherData element appears within an EncryptedData element.

<?xml version='1.0' ?>

<EncryptedData xmlns='

Type='http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml'>

</CipherData>

</EncryptedData>

XML encryption for an XML document in particular follows a slightly different method of encryption. XML encryption can be used to encrypt an element and/or element content. For example consider an xml document as below:

<?xml version= “1.0”?>

<Name>John Smith</Name>

<Title>Engineer</Title>

<Salary> 60000

</Salary>

</Employee>

For security reasons, we would like to encrypt SSN element and also content of<Bonus> element. This is done as shown below:

<?xml version='1.0' ?>

<Name>John Smith</Name>

<EncryptedData Type=' xmlns='

</CipherData>

</EncryptedData>

<Title>Engineer</Title>

<Salary> 60000

<Bonus>

<EncryptedData Type=' xmlns='

</CipherData>

</EncryptedData>

</Bonus>

</Salary>

</Employee>

The CipherData element can appear within an EncryptedData element or an EncryptedKey element. The CipherData element refers to the encrypted data when it appears inside an EncryptedData element and it refers to the encrypted key when it appears inside an EncryptedKey element.

We can also refer to external encrypted data or encrypted keys. This means that actual encrypted data or keys will be present somewhere else and not inside the encrypted XML file. In this case we will use CipherReference instead of the CipherValue child element inside CipherData. The actual encrypted data can be referenced through a URI.

XML encryption processing rules define three entities: the application, encryptor and the decryptor. Encryptor is the entity that does the encryption and creates a proper encrypted XML document. It is also responsible for the storage of the keys. The decryptor performs decryption operation on the <EncryptedData> element and gets all the necessary information needed for decoding .The result is then passed to the application. The application is responsible for validating this decoded output and converting them back to their original format. All this heavy duty operations can be delegated to a service known as XKMS.

XKMS

XKMS stands for XML Key Management Specification. Currently, it is at a developing stage. The XML Key Management Specification describes the process for distributing and registering public keys for use with the XML Signature and XML Encryption specifications. An XKMS service can relieve an application from doing all PKI implementations validating a digital certificate or checking its revocation status. In short, XKMS handles PKI issues like validation, verification and trust.

The two basic components that build XKMS are X-KISS and X-KRSS:

XML Key Information Service Specification(X-KISS) is a protocol to support the delegation by an application to a service of the processing of key information associated with an XML signature, XML encryption, or other public key. Its functions include the location of required public keys and describing the binding of such keys to identification information.[1] X-KISS allows a client to delegate part or all of the tasks required to process XML Signature <ds:KeyInfo> elements to an XKMS service. X-KISS defines the protocol for a trust service that resolves public key information as implemented by the XML Signature specification. X-KISS lets an application use a third party, such as a trusted certificate authority or a service provider to do all the things associated with PKI. X-KISS is compatible with industry-standard X.509 digital certificates and the Pretty Good Privacy (PGP) public key system.

XML Key Registration Service Specification(X-KRSS) is a protocol to support the registration of a key pair by a key pair holder, with the intent that the key pair subsequently is usable in conjunction with the XML Key Information Service Specification or higher level trust assertion service such as XML Trust Assertion Service Specification [XTASS][2]. X-KRSS describes the process for a Web service that registers public key information. Public key pairs registered through X-KRSS can be used in conjunction with X-KISS and other trust assertion services. If a client generates the key pair, X-KRSS requires proof that the client holds the private key. If the registration service generates the key pair, the specification provides a way to communicate the private key to the client. The registration protocol can also be used to recover a private key if necessary.

Additionally, a client of the registration service can request that certain information be bound to a public key, such as a name, an identifier, or other attributes. X-KRSS specifies the registration of RSA and DSA keys. It also has a framework for extending the registration process to support other algorithms such as Diffie-Hellman, etc.

Any service providing XKMS has to consider security issues like replay attacks, denial of service, security of private key, key recovery, etc.

Applications of XML security

Web services use XML signatures to sign SOAP messages and XML encryption to encrypt them. Microsoft® Office InfoPath™ uses XML signatures to sign partial or whole forms. The XML manifests for ClickOnce®-based applications, new in Visual Studio® 2005, also use XML signatures. The .NET Framework 1.x includes an object model for the XML Signature standard, and the .NET Framework 2.0 adds additional support, while adding an object model for XML encryption as well. Another product that contains an implementation of XML Signature recommendations is RSA’s Cert-J, which is a PKI toolkit for Java. The Security Association Markup Language (SAML) is one language which is using XML to provide security functions like authentication, authorization and access control functions. Another upcoming technology is XML Trust Assertion Service Specification (XTASS), a standardized way to make trust assertions for business partner relationships, initiated by Verisign.

Conclusion

Data security is implemented at various levels. Different methods are used by various databases to store data securely. Similarly, different file systems provide methods for storing file securely. Also, XML security system can be used to provide security to data that is transacted over the Internet.

Reference:

, April 2005
Exploring XML Encryption, Part 1, , April 2005
Dournaee Blake, XML Security, RSA PRESS, 2001, 379 pages.
April 2005
-windows encrypted file system. OS taking care of file security.
- Platform/OS neutral secure file storage.

[1]

[2]