Product Documentation

    Among the many elements used by the appliance, and which are defined in the SAKA XSD file (SAKA.xsd), is the SBI element; it defines the structure of the XML input file for batch operations. This element is used for all four (4) types of cryptographic operations—encryption, decryption, deletion, and search.

    All sub-elements of the SBI element are mandatory. Failure to include values for all SBI sub-elements will prevent the batch job from executing. A sample of the input file for different transactions is shown below, followed by an explanation:

    #

    SBI XML Content

    1

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

    2

    		 
    <skles:SKLESBatchInput

    3

    		 
    xmlns:skles='http://strongkeylite.strongauth.com/SKLES201009'>

    4

    		 
    <skles:DomainId>1</skles:DomainId>

    5

    		 
    <skles:JobId>X1234-20100920T211723</skles:JobId>

    6

    		 
    <skles:Transaction>Encrypt</skles:Transaction>

    7

    		 
    <skles:InputNumber>5</skles:InputNumber>

    8

    		 
    <skles:InputValues>

    9

    		 
    <skles:Input>1111222233330001</skles:Input>

    10

    		 
    <skles:Input>1111222233330002</skles:Input>

    11

    		 
    <skles:Input>1111222233330003</skles:Input>

    12

    		 
    <skles:Input>1111222233330004</skles:Input>

    13

    		 
    <skles:Input>1111222233330005</skles:Input>

    14

    		 
    </skles:InputValues>

    15

    		 
    </skles:SKLESBatchInput>

    The following table explains each line of the above XML file:

    #

    SBI XML Content Explanation

    1

    The start of the XML file.

    2

    The start of the SBI element. Note that all elements in this example are qualified with the skles prefix.

    3

    The namespace definition to which this schema instance conforms; in this case, http://strongkeylite.strongauth.com/SKLES201009.

    4

    The DomainID element—the value for this element is 1. This value is mandatory—all cryptographic operations in SAKA operate within encryption domains, and without a domain ID, the appliance would not know which domain to use for processing the batch file. A valid numerical domain identifier is necessary.

    5

    The JobID element identifies a unique job name that the client application can use to identify its input/output XML files. The same JobID is written out in the output XML file by the appliance. In this example, the JobID is X1234-20100920T211723. There are no rules about what to use for a JobID, but it is helpful to have the source application name and the date-timestamp of the creation of the input file.

    6

    The Transaction element identifies the type of cryptographic operation to perform on each input element in the file. In this example, the batch file is requesting the Encrypt transaction. Each input file may specify only a single operation; this operation will be performed on all input records that follow. The four valid values for this element are: Encrypt, Decrypt, Delete, and Search.

    7

    The InputNumber element identifies the number of input records in this file. While this is helpful to human readers, the appliance processes exactly as many input records exist in the file regardless of what the InputNumber element states.

    8

    The InputValues element signals the start of all input records.

    9–13

    Each Input element has precisely one sensitive data value. This can be anything—up to a maximum of 1024 characters long. The appliance processes every single record as it reads them from the file. A missing or invalid value will cause the termination of the job on the appliance, leaving a partially processed output file. Thus it is important that the structure of the XML input file be verified against the SAKA schema before submitting the job to the appliance.

    14

    The closing InputValues tag.

    15

    The closing SBI tag.

    An example of the SBI element for a decryption operation is shown below:

    #

    SBI Decrypt XML Example

    1

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

    2

    		 
    <SKLESBatchInput

    3

    		 
    xmlns='http://strongkeylite.strongauth.com/SKLES201009'>

    4

    		 
    <DomainId>1</DomainId>

    5

    		 
    <JobId>JOB123-20100920T111353</JobId>

    6

    		 
    <Transaction>Decrypt</Transaction>

    7

    		 
    <InputNumber>5</InputNumber>

    8

    		 
    <InputValues>

    9

    		 
    <Input>9999000000000786</Input>

    10

    		 
    <Input>9999000000000787</Input>

    11

    		 
    <Input>9999000000000788</Input>

    12

    		 
    <Input>9999000000000789</Input>

    13

    		 
    <Input>9999000000000790</Input>

    14

    		 
    </InputValues>

    15

    		 
    </SKLESBatchInput>

    The following table explains each line of the above XML that differs from the first example:

    #

    SBI Decrypt XML Explanation

    2

    The start of the SBI element. Elements in this example are unqualified because the default namespace definition in line 3 is associated with an empty prefix (nothing after the xmlns).

    6

    The Transaction element identifies the Decrypt operation.

    9–13

    Each Input element has precisely one token—the Pseudo Number (PSN)—that was originally assigned by the appliance when it was first encrypted. This token is required to locate the encrypted data in the appliance; decrypt it and write it to the output file.

    The XML files for Delete and Search operations are identical to the two presented here. They only differ in the Transaction element and the type of data presented in the Input elements; deletion operations take tokens as their input value, while search operations require the original plaintext data.