Posts Tagged ‘encryption

SSL/TLS Cipher Suites

A cipher suite combines four kinds of security features, and is given a name in the SSL protocol specification. Before data flows over a SSL connection, both ends attempt to negotiate a cipher suite. This lets them establish an appropriate quality of protection for their communications, within the constraints of the particular mechanism combinations which are available. The features associated with a cipher suite are:

A given implementation of SSL will support a particular set of cipher suites, and some subset of those will be enabled by default. Applications have a limited degree of control over the cipher suites that are used on their connections; they can enable or disable any of the supported cipher suites, but cannot change the cipher suites that are available.

Tags : , , , , , , , , , ,

Limitations of Modern Cryptosystems

Before exploring quantum key distribution, it is important to understand the state of modern cryptography and how quantum cryptography may address current digital cryptography limitations. Since public key cryptography involves complex calculations that are relatively slow, they are employed to exchange keys rather than for the encryption of voluminous amounts of date. For example, widely deployed solutions, such as the RSA and the Diffie-Hellman key negotiation schemes, are typically used to distribute symmetric keys among remote parties. However, because asymmetric encryption is significantly slower than symmetric encryption, a hybrid approach is preferred by many institutions to take advantage of the speed of a shared key system and the security of a public key system for the initial exchange of the symmetric key. Thus, this approach exploits the speed and performance of a symmetric key system while leveraging the scalability of a public key infrastructure.

However, public key cryptosystems such as RSA and Diffie-Hellman are not based on concrete mathematical proofs. Rather, these algorithms are considered to be reasonably secure based on years of public scrutiny over the fundamental process of factoring large integers into their primes, which is said to be “intractable”. In other words, by the time the encryption algorithm could be defeated, the information being protected would have already lost all of its value. Thus, the power of these algorithms is based on the fact that there is no known mathematical operation for quickly factoring very large numbers given today’s computer processing power.

Secondly, there is uncertainty whether a theorem may be developed in the future  or perhaps already available that can factor large numbers into their primes in a timely manner. At present, there is no existing proof stating that it is impossible to develop such a factoring theorem. As a result, public key systems are thus vulnerable to the uncertainty regarding the future creation of such a theorem, which would have a significant affect on the algorithm being mathematical intractable. This uncertainty provides potential risk to areas of national security and intellectual property which require perfect security.

In sum, modern cryptography is vulnerable to both technological progress of computing power and evolution in mathematics to quickly reverse one way functions such as that of factoring large integers. If a factoring theorem were publicized or computing became powerful enough to defeat public cryptography, then business, governments, militaries and other affected institutions would have to spend significant resources to research the risk of damage and potentially deploy a new and costly cryptography system quickly.

Tags : , , , , , , , , ,

Encrypting XML Messages

The following instructions describe how to encrypt outgoing responses for a handler or basic virtual service object. You can also configure encryption for service descriptors, in which case the outgoing request is encrypted. The procedure is similar to that described here.

To set up encryption of outgoing responses:

Step 1

While logged on to the console as an Administrator user or as a Privileged user with the Routing role, click Virtual Services link in the navigation menu.

Step 2

Click the name of the virtual service object for which you want to configure XML encryption.

As mentioned, for XML encryption controls to be enabled for the service definition, its message specification must indicate that it is XML data. It cannot be raw byte data, for example, which is the default for non-SOAP HTTP service definitions. The Response Message Specification pane indicates how the message content is treated, whether as XML or as raw byte. If necessary, change message-body handling settings by:

  1. Clicking the Edit link in the heading of the Response Message Specification subsection of the Outgoing Response section of the page.
  2. Use the editor’s controls to specify that the handler treat the bodies of outgoing response messages as XML.
  3. Click Save Changes.

Step 3

In the service definition settings page, specify content encryption by clicking the Add Encryption Listor the Enable link in the XML Encryption pane of the message processing section.

Step 4

In the XML Encryption configuration page, use the following controls to specify how encryption occurs:

  1. The public key attribute of the consumer that sent the original request message
  2. The public key used to sign the original request message.
  3. A public key set by an extension created with the ACE XML Gateway SDK. This is onlyavailable if any extensions are on the ACE XML Manager. This ability is useful if an extension performs client authentication and it has access to the user’s public key, which can then be used in message processing.
  4. Any public key that a Consumer Certificate Resource provides to the ACE XML Manager. The Upload button allows you to add as a named Consumer Certificate Resource an XML certificate or keypair from the local file system or by URL.

You can create as many XPath expressions as necessary to select elements to encrypt. For SOAP services, if the expression matches multiple elements in the message, all are encrypted. For HTTP post body, only the first element is matched.


Tags : , , , , , , , , , , , , , , , , , ,

Desirable Quantum Key Distribution Attributes

Broadly stated, QKD(Quantum Key Distribution) offers a technique for coming to agreement upon a shared random sequence of bits within two distinct devices, with a very low probability that other devices(eavesdroppers) will be able to make successful inferences as to those bits’ values. In specific practice, such sequences are then used as secret keys for encoding and decoding messages between the two devices. Viewed in this light, QKD is quite clearly a key distribution technique, and one can rate QKD’s strengths against a number of important goals for key distribution, as summarized in the following paragraphs.

Confidentiality of Keys : Confidentiality is the main reason for interest in QKD. Public key systems suffer from an ongoing uncertainty that decryption is mathematically intractable. Thus key agreement primitives widely used in today’s Internet security architecture, e.g., Diffie-Hellman, may perhaps be broken at some point in the future. This would not only hinder future ability to communicate but could reveal past traffic.Classic secret key systems have suffered from different problems, namely, insider threats and the logistical burden of distributing keying material. Assuming that QKD techniques are properly embedded into an overall secure system, they can provide automatic distribution of keys that may offer security superior to that of its competitors.

Authentication : QKD does not in itself provide authentication.Current strategies for authentication in QKD systems include prepositioning of secret keys at pairs of devices, to be used in hash-based authentication schemes, or hybrid QKD-public key techniques. Neither approach is entirely appealing. Prepositioned secret keys require some means of distributing these keys before QKD itself begins, e.g., by human courier,which may be costly and logistically challenging. Furthermore, this approach appears open to denial of service attacks in which an adversary forces a QKD system to exhaust its stockpile of key material, at which point it can no longer perform authentication. On the other hand, hybrid QKD-public key schemes inherit the possible vulnerabilities of public key systems to cracking via quantum computers or unexpectedadvances in mathematics.

Sufficiently Rapid Key Delivery : Key distribution systems must deliver keys fast enough so that encryption devices do not exhaust their supply of key bits. This is a race between the rate at which keying material is put into place and the rate at which it is consumed for encryption or decryption activities. Today’s QKD systems achieve on the order of 1,000 bits/second throughput for keying material, in realistic settings, and often run at much lower rates. This is unacceptably low if one uses these keys in certain ways, e.g., as one-time pads for high speed traffic flows. However it may well be acceptable if the keying material is used as input for less secure (but often secure enough) algorithms such as the Advanced Encryption Standard. Nonetheless, it is both desirable and possible togreatly improve upon the rates provided by today’s QKD technology.

Robustness : This has not traditionally been taken into account by the QKD community. However, since keying material is essential for secure communications, it is extremely important that the flow of keying material not be disrupted, whether by accident or by the deliberate acts of an adversary (i.e. by denial of service). Here QKD has provided a highly fragile service to date since QKD techniques have implicitly been employed along a single point-to-point link. If that link were disrupted,whether by active eavesdropping or indeed by fiber cut, all flow of keying material would cease. In our view a meshed QKD network is inherently far more robust than any single point-to-point link since it offers multiple paths for key distribution.

Distance- and Location-Independence : In the ideal world,any entity can agree upon keying material with any other(authorized) entity in the world. Rather remarkably, the Internet’s security architecture does offer this feature – any computer on the Internet can form a security association with any other, agreeing upon keys through the Internet IPsec protocols. This feature is notably lacking in QKD, which requires the two entities to have a direct and unencumbered path for photons between them, and which can only operate fora few tens of kilometers through fiber.

Resistance to Traffic Analysis : Adversaries may be able to perform useful traffic analysis on a key distribution system,e.g., a heavy flow of keying material between two points might reveal that a large volume of confidential information flows, or will flow, between them. It may thus be desirable to impede such analysis. Here QKD in general has had a rather weak approach since most setups have assumed dedicated, point-to-point QKD links between communicating entities which thus clearly lays out the underlying key distribution relationships.


Tags : , , , , , , , , , , , , , , , , , , , , , , , ,

XML Encryption and Access Control

Subtree encryption (element wise)

The two published proposals by [Imamura] and [Simon, LaMacchia] have in common that they take a complete sub tree (descendant-or-self(), maybe with of without attributes of self()), serialize this subtree into a text representation, encrypt it using some encryption mechanism like a symmetric cipher and replace the unencrypted part of the document with the resulting cipher text.

The subtree encryption is an end-to-end-security approach, in which the document includes all sensitive information in encrypted (secured) form. It allows to include multiple encrypted subtrees, and depending on the choosen model and granularity, it is possible to select even single attributes for encryption. In the following illustration, the “Public Nodes” do not need to be confidential (encrypted),but the one at the bottom is encrypted in the subtree.

To encrypt a subtree, the nodes that should be secured are selected:


Server-side Access Control

The server-side access control scenarios with flexible in their content model:

Server-side AC can completely restructure and rebuild the tree, based on the access control lists. It is not forced to make a complete subtree opaque, but it can let some elements childs visible (unencrypted) to the client without enforcing the root of the subtree (self()) being visible.


Tags : , , , , , , , , , , ,

XOM, a secure architecture in Embedded Systems

XOM is the acronym of eXecute Only Memory. XOM wishes to completely secure an architecture. Moreover XOM is supposed to be sure and claimed that hardware solutions are more efficient than the software ones. So XOM mostly relies on hardware mechanisms to ensure security. New primitives are provided within the OS in orderto handle key and signature manipulation. The name of the OS extension is XOMOS. The main features of XOM are : memory ciphering and hashing, data and program partitioning, interruption and context switching protection.

Each partition of the memory is associated with a secret key to decrypt its content (the session key in Figure 3). The session key is obtained with the XOM key table which establishes the connection between the session key and the secret keyof a specific partition of the memory. The secret key is also encrypted with an asymmetric encryption. The key (private keyin Figure 3) required for the asymmetric decryption is stored in the secure zone of the architecture. The use of the hash solution is classic. The signature result of the hash algorithm is compared with the original one to validate the integrity of the hashed message. In addition the data stored in cache memory is associated with an identifier. When a task wants to use adata, the identifier of the task must be the same as the data one, in that case it means the task is allowed to read and modify the data. This feature protects the system from malicious program which tries to get illegal information. XOM proposes hardware security primitives to protect cipher keys and hash signatures which are essential to guarantee the architecture durability.

Fig. 3. XOM architecture

The last point of the XOM solution concerns the preemption within the OS which has similarities with the management ofthe interruptions. The context must be saved. It is essential to store and to protect the context in order to fend off an attack who aims to change some register values. XOM ciphers and hashes the switching context which is interesting for a solution with an OS. XOMOS can be seen as an extension of a non-secure OS which brings new security primitives (ciphering and hashing).

All the protections added by the solution have a cost. The first one concerns the implementation of XOM in an existing OS. A work is necessary on the kernel to add the instructions which help for the use of the security primitives. All this work is invisible for the user of the kernel. A real overhead appears inthe cache management. The number of cache miss raises from 10 to 40%. It depends on the kernel operation. This raise is due to the information added in the cache to secure the data. Data are associated with the identifier of the task. It means some parts of the cache are used to store the identifier. The protection of the context switching also brings an increase of the number of cycles to store the context and to protect it.


Tags : , , , , , , , , , , , , , , , , , , , ,