Emerging Security Technologies for Grid

2.2 Grid Security

2.2.3 Emerging Security Technologies for Grid

The Open Grid Services Architecture (OGSA) introduces both new opportunities and new challenges for grid security. It makes sense that OGSA security should lever- age as much as possible the existing and emerging web services security standards, and to augment these only when needed. Emerging web services security specifications address standard methods for authentication and establishment of security contexts and trust relationships in WS-SecureConversation [93] and WS-Trust [94]; standard formats for security token exchange in WS-Security [132] and SAML [37]; and expression of web service security policy in WS-Policy [156] and XACML [129]. These specifications have been exploited by grid developers to create uniform and inter-operable methods to be used in grid security. For more details and examples of OGSA security and web services security, see [162].

We remark that the adoption of web services security technologies is orthogonal to the application of identity-based cryptography in grid security. The use of web services seems to be mainly driven by the critical need for inter-operable and scalable grid systems. Therefore, integration between web services security and identity- based cryptography will not be covered at length in this thesis. We only intend to discuss the possible impacts of identity-based cryptography on the underlying fundamental XML security technologies from which web services security are built. These include XML Signature and XML Encryption. In the remainder of this sec- tion, we will discuss some basic features of XML Signature and XML Encryption, and the message-level security that is provided by WS-Security.

XML Signature. XML Signature [53] provides an XML syntax defined for digital signatures. An XML Signature can be applied to some or all the content of one or more XML documents or SOAP messages (refer back to page 25 for the definition of SOAP). Also, a single XML document can contain multiple XML Signatures. They are represented by a Signature element which has the structure shown in Figure 2.6. (Notation: ? denotes zero or one occurrence; + indicates one or more occurrences; and ∗ represents zero or more occurrences.)

2.2 Grid Security <Signature Id?> <SignedInfo> <CanonicalizationMethod/> <SignatureMethod/> (<Reference URI?> (<Transforms>)? <DigestMethod> <DigestValue> </Reference>)+ </SignedInfo> <SignatureValue> (<KeyInfo>)? (<Object ID?>)* </Signature>

Figure 2.6: The shorthand XML schema for <Signature>.

nature generation. Given a data object, the reference generation operation applies a Transform algorithm to the data object, calculates a digest value over the resulting data object, and creates a Reference element. Subsequently, the signature generation operation creates a SignedInfo element. It then performs canonicaliza- tion13 _{on the SignedInfo element before signing it with the algorithms specified in}

SignedInfo. It then constructs a Signature element.

Verifying an XML Signature follows the following process. Given the SignedInfo element, the reference validation operation performs canonicalization and obtains the data object pointed to in the Reference element. It applies a Transform algorithm and computes a digest value with the algorithm specified in the Reference element. The calculated digest value is compared with the DigestValue in the Reference element. The verification fails if there is any mismatch. Subsequently, the signature verification operation obtains the verification key from the KeyInfo element. Using the output of the SignedInfo canonicalization, it then runs the algorithm specified in the SignatureMethod, taking as input the SignatureValue. The signature verification passes if and only if the resulting value matches the value in the SignedInfo element.

13_{Canonicalization is a process of converting data that has more than one possible representation} into a standard representation. This is to ensure that two similar data objects with different XML data representations will give the same digest value. This is essential for preserving data integrity, a requirement for the signature scheme to work properly.

2.2 Grid Security

Figure 2.7: The shorthand XML schema for <EncryptedData>.

XML Encryption. Meanwhile, XML Encryption [54] is designed to keep all or part of a SOAP message secret. It also allows a sender to encrypt different sections of an XML document with different keys, thus making different sections of the document available to different recipients. Figure 2.7 shows the shorthand schema for an XML Encryption.

In many ways, the EncryptedData element is simpler than the Signature element because it is more self-contained. The EncryptedData element represents a single resource being encrypted and it does not contain pointers to multiple items. On the other hand, the Signature element contains a collection of pointers that represent what is being signed.

To encrypt XML data, the XML Encryption scheme first chooses an encryption algorithm for the EncryptionMethod element. It then specifies an encryption key and serialises the message data to obtain octets that are input to the encryption algorithm. Then the actual encryption of the data is performed and the result is placed in the CipherData element before the associated EncryptedData element is built.

For decryption, the XML Encryption scheme obtains the necessary information for decryption such as the encryption algorithm and the associated key information from the EncryptedData element. The corresponding encryption key is extracted from

2.2 Grid Security

the KeyInfo element before the actual decryption of the CipherData takes place.

SOAP Message Security. The confidentiality and integrity of SOAP messages can be protected through WS-Security. The aim of WS-Security is to use existing technologies to provide a common format for security of SOAP messages. Message- level security protects messages in a different way from transport-level security. The former allows each message to be encrypted or signed independently and thus self- protected. Thus, message protection persists wherever the message travels. How- ever, the latter only provides security to messages transmitted from one point to another in a secure channel, e.g. established using the TLS protocol. The down- side of the flexibility that message-level security offers is that it results in a rather complex message that employs many security standards such as XML Signature, XML Encryption, and a common security token such as an X.509 certificate. This may raise considerable performance issues when transporting secure SOAP messages from one entity to another. The performance may be worse when the message has multiple signatures or data encrypted with different keys targeted at different recipients.

Security-related information targeted at a specific recipient is provided through a SOAP security header. There are three types of elements that may make up the header:

(i). Security tokens: These are data used for authentication or authorization. Ex- amples of security tokens are username/password, X.509 certificate and Ker- beros ticket.

(ii). Signatures: These are usually obtained as the result of signing part or all of the SOAP body using XML Signature.

(iii). ReferenceList or EncryptedKey: This is a reference list that contains refer- ences to all the possible different EncryptedData elements, or key information used by a WS-Security processor to decrypt the encrypted data.

Many grid scenarios require end-to-end message protection over a route that tra- verses one or more intermediate components such as firewalls or routers. To meet the

In document On the Application of Identity-Based Cryptography in Grid Security (Page 41-45)