The core communication protocol between the SKCL and the SKS server is an XML-based protocol. Currently, there are only two message types, and three response types defined, which are described below.

StrongKey leverages the OASIS Web Services Security protocol for providing message-level security to the core protocol. This enables StrongKey to digitally sign requests and responses, and optionally encrypt responses without burdening the core protocol for security reasons.

The core protocol consists of the following two message requests:

1

A request for a new (or existing) symmetric key.

2

A request for a Key Cache Policy (KCP).

The request for a symmetric key is as follows:

<symkey:SymkeyRequest xmlns:symkey="http://www.strongauth.com/2006/01/symkey">

<gkid>0-0</gkid>

</symkey:SymkeyRequest>

The GKID element (Global KeyID) is the only required element in the XML “document”. A request for 0-0 always indicates a request for a new symmetric key. A request for an existing key would have real numbers in it, such as 1-23, 2-42, 5-732, etc.

The first part of the GKID is the unique server number in an EKMI, while the second part of the GKID is the unique key ID generated on that server. Combined, the GKID always provides a unique key identifier within an enterprise of any size.

The same request, when wrapped in the WSS protocol, resembles the following:

<?xml version="1.0" encoding="UTF-8"?>

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">

<SOAP-ENV:Header>

<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" SOAP-ENV:mustUnderstand="1">

<wsse:BinarySecurityToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="XWSSGID-1154633872103-139718344">MIIDfDCCAmSgAwIBAgIIAe/AvliGc3AwDQYJKoZIhvcNAQELBQAwZzEmMCQGA1UEAxMdU3Ryb25n

S2V5IERFTU8gU3Vib3JkaW5hdGUgQ0ExJDAiBgNVBAsTG0ZvciBTdHJvbmdLZXkgREVNTyBVc2Ug

T25seTEXMBUGA1UEChMOU3Ryb25nQXV0aCBJbmMwHhcNMDYwNzI1MTcxMDMwWhcNMDcwNzI1MTcy

MDMwWjBtMREwDwYKCZImiZPyLGQBARMBMjEZMBcGA1UEAxMQUE9TIFJlZ2lzdGVyIDIyMjEkMCIG

A1UECxMbRm9yIFN0cm9uZ0tleSBERU1PIFVzZSBPbmx5MRcwFQYDVQQKEw5TdHJvbmdBdXRoIElu

YzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyAmxMZhYA8wHJ4UE4b61s51JVWe4Fygj4MCf

U7LA3JhpUS4TlX0XFWqrcmltLOiVG7YBFarJFluBFJW2X6q8FuvUprv4V9nJrgiwAPtkiRyIx96n

qKXIxkUlQ4idlEg1AZI9dEdf4Y5cqBBCygPYnBoTudglM7R47AjR4nr4ks8CAwEAAaOBqTCBpjAO

BgNVHQ8BAf8EBAMCBLAwHQYDVR0OBBYEFOIOrWrZo0LdBRLVncRAwLBqVZpCMB8GA1UdIwQYMBaA

FPTYwEHoJG4iFVHRnt2EWxGluAQVMBgGA1UdIAQRMA8wDQYLKwYEAdISg30BBAEwOgYDVR0fBDMw

MTAvoC2gK4YpaHR0cDovL2RlbW8uc3Ryb25na2V5Lm9yZy9kZW1vLXN1Yi1jYS5jcmwwDQYJKoZI

hvcNAQELBQADggEBACK05PtvZD4WPglOe+EHUiApzFyCdRzf0pFZtxRwG9lR1PZUWUjmwTNfGFsL

S6kyoHgUfVa5fpT1EU1mXUB/Lmo3hFGyprZjfmD7DwuBcYgmZHv7yHrmGOMIOXjFTACvHpM0vOce

hVx2e4VE0yhBLu/ldH9awGGDp6Bk2XzxqQcs8y6ZzOXZAnPgKQZdjbFKERSsy/d1D8pk5baBk4bd

Zh568OcaUrbm9ZReRVTVaY5qiQpkOU+tDrBSj/HIL6GAqegYllkz6KYCy6RVOy6iVVSjHocDqdJr

EVOR+ds6xn8mmojdlERrILmuxiLpibPp609SfnDIxNlzLwe5g7ep3lc=</wsse:BinarySecurityToken>

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<ds:SignedInfo>

<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">

<InclusiveNamespaces xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="wsse SOAP-ENV"/>

</ds:CanonicalizationMethod>

<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

<ds:Reference URI="#XWSSGID-1154633886532522603690">

<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

<ds:DigestValue>8OELMetSbQPDZveXoDd7kSjJYdU=</ds:DigestValue>

</ds:Reference>

<ds:Reference URI="#XWSSGID-1154633886536485581557">

<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

<ds:DigestValue>vPT0dPS/4WzHzi9RNHZdLwTHv9k=</ds:DigestValue>

</ds:Reference>

</ds:SignedInfo>

<ds:SignatureValue>jvYXz2ScnuSbRWhTwhhCp56MdNyVuz6G3p5SdkX4Y4B7YwDg/ZOx9ahBoiWe/C4/sIo05DEYXRha

zvchzVl5PeA1IwY6BVky0P8xhyfGBDWDZgenMvAeSfhocbDsz1MueAN8HOdpNoMPp7b0QG+cB5g7

Y0qwD9AnlZCKx5ClB78=</ds:SignatureValue>

<ds:KeyInfo>

<wsse:SecurityTokenReference xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-115463388652624606128">

<wsse:Reference URI="#XWSSGID-1154633872103-139718344" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>

</wsse:SecurityTokenReference>

</ds:KeyInfo>

</ds:Signature>

<wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-1154633886536485581557">

<wsu:Created>2006-08-03T19:38:06Z</wsu:Created>

<wsu:Expires>2006-08-03T19:38:11Z</wsu:Expires>

</wsu:Timestamp>

</wsse:Security>

</SOAP-ENV:Header>

<SOAP-ENV:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-1154633886532522603690">

<symkey:SymkeyRequest xmlns:symkey="http://www.strongauth.com/2006/01/symkey">

<gkid>0-0</gkid>

</symkey:SymkeyRequest>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

While this appears extremely busy and excessive, it does provide a significant amount of security on a highly insecure internet, with a great deal of flexibility. More details on the WSS protocol can be found at OASIS' website at http://www.oasis-open.org.

The second type of request is when a client requests for a policy object that tells the SKCL whether to cache symmetric keys locally (always encrypted and digitally signed), how long to cache them if allowed, and how many keys to cache, etc. The core protocol for a KCP request looks like the following:

<kcpr:KCPRequest xmlns:kcpr="http://www.strongauth.com/2006/01/symkey#KCPRequest"/>

The XML “document” is so simple that it needs no elements. The reason is the WSS overlay. Since the message is digitally signed, the server determines who the requestor is based on the certificate DN (after the signature has been validated as being from a trusted certificate), and then responds with the appropriate response. There is no need for any element in the request, since the server only accepts one type of request for a KCP.

The SKS server provides one of three types of responses to the two request types:

1

It returns a new (or existing) symmetric key

2

It returns a KeyCachePolicy

3

It returns a SOAP Fault, indicating an error of some kind

A successful response to a symmetric key request (without the WSS overlay) resembles the following:

<xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:symkey="http://www.strongauth.com/2006/01/symkey#">

<ds:KeyInfo>

<ds:KeyName>2-2</ds:KeyName>

</ds:KeyInfo>

<xenc:CipherData>

<xenc:CipherValue>CKd4hXZkFGXagTaSPXfOzGgmRVQDik377GZ8hbXfL/XxyzynxGRCS1QUusbgSBqXqjq8goRLcb6l

rDtyM+q3MeWIv0/BAoZyUJrGGflSJ7OqVwH1vClmhrMfqPmPTWlvBznsPJeG9ICb/kPNFQEFyn8Y

8pRnbgc38XkMl7uPWAo=</xenc:CipherValue>

</xenc:CipherData>

<xenc:EncryptionProperties>

<xenc:EncryptionProperty>

<symkey:KeyUsePolicy>

<symkey:pid>4</symkey:pid>

<symkey:name>DES-EDE KeyUsePolicy</symkey:name>

<symkey:start_date>1969-12-31 16:00:00.0</symkey:start_date>

<symkey:end_date>1969-12-31 16:00:00.0</symkey:end_date>

<symkey:duration>0</symkey:duration>

<symkey:tx_allowed>10</symkey:tx_allowed>

<symkey:policy_type>Tx</symkey:policy_type>

<symkey:algorithm>http://www.w3.org/2001/04/xmlenc#tripledes-cbc</symkey:algorithm>

<symkey:keysize>192</symkey:keysize>

<symkey:status>Active</symkey:status>

</symkey:KeyUsePolicy>

</xenc:EncryptionProperty>

</xenc:EncryptionProperties>

</xenc:EncryptedKey>

The response, essentially, is an EncryptedKey element from the XMLEncryption schema, a W3C standard (see http://www.w3c.org for details).

The most important elements of the response are:

1

The <ds:KeyName> element, which provides the GKID of the symmetric key

2

The <xenc:CipherValue> element, which contains the encrypted symmetric key. The key is encrypted with the requestor's RSA public-key of their transport certificate. This ensures that only the legitimate owner of that RSA private-key can decrypt the symmetric key here.

3

The <xenc:EncryptionProperty> element which contains a StrongKey-defined object, the KeyUsePolicy (KUP). The KUP contains policy elements that direct the SKCL how to use the key, when to use, and for how many encryption operations.

In this particular example, the policy indicates that this is a 3DES key, 192-bits in length and may be used only for ten (10) encryption transaction (Tx) operations. More details about the KUP object are provided in the StrongKey Reference Manual.

Click here to see how this response from the SKS server looks when overlayed with the WSS protocol.

A successful response to a KCP request (without the WSS overlay) resembles the following:

<kcp:KeyCachePolicy xmlns:kcp="http://www.strongauth.com/2006/01/symkey#KeyCachePolicy">

<kcp:kcpid>2</kcp:kcpid>

<kcp:name>Active KeyCachePolicy for all devices</kcp:name>

<kcp:description>This is a modified description for KCPID 2</kcp:description>

<kcp:start_date>2006-08-02 11:49:13.0</kcp:start_date>

<kcp:end_date>2010-10-12 12:31:35.0</kcp:end_date>

<kcp:maxnewkeys>0</kcp:maxnewkeys>

<kcp:maxnewdays>0</kcp:maxnewdays>

<kcp:maxusedkeys>5</kcp:maxusedkeys>

<kcp:maxuseddays>60</kcp:maxuseddays>

<kcp:usefirst>Cache</kcp:usefirst>

<kcp:status>Active</kcp:status>

</kcp:KeyCachePolicy>

More details about the KCP object are provided in the StrongKey Reference Manual. Click here to see how this response from the SKS server looks when overlayed with the WSS protocol.

A failure to get a successful response results in a SOAP Fault, which resembles the following

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">

<SOAP-ENV:Header>

ERROR: Other error reported; please review logs for details

Server error message is: No authorization to request this key: 2-2; if you believe this response is an error, please contact your Security Officer

</SOAP-ENV:Header>

<SOAP-ENV:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-11546444952951942616024">

<SOAP-ENV:Fault>

<faultcode xmlns:skf="http://www.strongauth.com/2006/01/symkey#SymkeyFault">skf:SymkeyFault</faultcode>

<faultstring>symkey.sks.msg.severe.0085</faultstring>

<detail>

<EndEntity>

<EEID>2</EEID>

<DN>O=StrongAuth Inc,OU=For StrongKey DEMO Use Only,CN=POS Register 222,UID=2</DN>

<Status>Active</Status>

</EndEntity>

<Request>

<RID>3</RID>

<GKID>2-2</GKID>

<Timestamp>2006-08-03 15:34:55.0</Timestamp>

<Disposition>Failed</Disposition>

</Request>

</detail>

</SOAP-ENV:Fault>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>