1. Purpose and Scope

The purpose of this standard is to define the data formats for authentication, encryption, and assurances in order to provide integrity, confidentiality, and verification and non-repudiation of origin for two levels of exchange of Electronic Data Interchange (EDI) formatted data defined by Accredited Standards Committee (ASC) X12. These security services can be applied at either the functional group level or the transaction set level or both.

This standard defines data formats for the following optional mechanisms:

• Authentication of EDI encoded data

• Compression of EDI encoded data

• Encryption of EDI encoded data

• Assurances applied to EDI encoded data

• Assurances applied to EDI encoded data and passed independent of EDI encoded data

• Non-repudiation of Origin

• Non-repudiation of Receipt

• Security protocol error reporting

The business requirements addressed in this standard for the security of EDI-formatted data encompass:

• Verification of the security originator to the security recipient

• Verification of assurance originator to any interested party ("non repudiation of sender")

• Electronic signatures, including expression of business purpose for applying each of several possible multiple signatures and date-time stamp

• Verification of data integrity ("error detection," "hash totals," "control totals")

• Confidentiality of business data

• Detection of replay (e.g., duplication), insertion/modification/deletion, or impersonation

2. Referenced and Related Standards

This standard is used with the ASC X12 series of standards on electronic data interchange.

The following material is from The Internet Engineering Task Force (IETF®). The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet.

The following verbatim text is from the cited document as noted immediately below.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

Key words for use in RFCs to Indicate Requirement Levels

3. Definitions and Common Abbreviations

X12.6 Application Control Structure provides formal definition of terminology related to the electronic data interchange standards developed by ASC X12.

3.1 Definitions

Algorithm
A clearly specified mathematical process for computation; a set of rules which, if followed, will give a prescribed result.

Assurance Originator
The entity responsible for generating an assurance.

Assurance Recipient
The entity responsible for verifying an assurance.

Assurances
A generalization of the concept of "electronic signature" which includes similar concepts such as notarization or a secured time stamp.

Authentication
The verification of the source, uniqueness, and integrity of a message (definition used in ANSI X9.9).

Ciphertext
Encrypted (enciphered) data.

Cryptographic Equipment
Hardware or software that performs cryptographic functions (e.g., encryption, authentication, key generation).

Cryptographic Key (also Key)
A parameter that determines the transformation from plaintext to ciphertext or vice versa. For example, a DEA key is a 64-bit parameter consisting of 56 independent bits and eight bits which may be used as odd parity bits.

Cryptographic Service Message
Message used for transporting keys or related information used to control a keying relationship (ANSI X9.17).

Data Compression
Reduction in the size of a data stream by the use of specialized encoding techniques.

Data Key
A key used to encrypt and decrypt or to authenticate data (ANSI X9.17). NOTE: this standard requires that different keys be used for authenticating and encrypting the same plaintext.

Decryption
The process of transforming ciphertext into plaintext (ANSI X9.23).

Digital Signature
Electronic signature based on public key technology.

Digest
The output of a hashing algorithm.

Dis-embodied Signature
Electronic signature based on public key technology that is passed independent of the associated document.

Electronic Signature
Generic term covering techniques such as hashing, message authentication codes, or digital signatures.

Encryption
The process of transforming plaintext into ciphertext.

Hash
A (mathematical) function which maps values from a (possibly very) large set of values into a smaller range of values.

Initialization Vector (IV)
A value used as a starting point for the encryption of a data sequence to increase security by introducing additional cryptographic variance and to synchronize cryptographic equipment.

Interchange Partners
Two parties who have previously agreed to exchange data. A party and a key center exchanging cryptographic service messages do not constitute interchange partners.

Interoperability
The ability to exchange EDI data or cryptographic keys, both manually and in an automated environment, with any other party implementing this standard, providing that both implementations use compatible options of the relevant standards and compatible communications facilities.

Key
See CRYPTOGRAPHIC KEY.

Keying Material
The data (e.g., keys and IVs) necessary to establish and maintain cryptographic keying relationships (ANSI X9.17).

Keying Relationship
The state existing between interchange partners in which they share at least one data key or key-encrypting pair.

Message Authentication Code (MAC)
A cryptographically derived hash total that can be used to verify the security originator to the security recipient and so protects the integrity of the applicable data.

Non-Repudiation
Ability of a party to a data exchange to obtain irrevocable proof, verifiable that some aspect of the data exchange occurred.

Octet
Eight bits.

Parity
A measure of the number of "1" bits in a group of "0" and "1" bits; either odd, even, or not relevant (i.e., none).

Party
Business entity that controls the application system that originates or receives EDI formatted data.

Plaintext
Unencrypted (unenciphered) data; intelligible data that can be directly acted upon without decryption.

Private Key
One of two keys used with an asymmetric cryptographic algorithm. The private key is known only to one entity.

Pseudo-Random
A value is pseudo-random if it is approximately random.

Public Key
One of two keys used with an asymmetric cryptographic algorithm. The public key is known to everyone.

Random
A value is random if it has an equal probability of being selected from all possible values; hence it is unpredictable.

Replay
The process of recording and repeating a message at a later time.

Secret Key
A key, used with a symmetric cryptographic algorithm, that is shared between the two entities.

Security Originator
The entity responsible for and authorized to apply cryptographic protection to a secured-body. NOTE: the security originator is logically distinct from the application sender.

Security Recipient
The entity responsible for verifying that the secured-body has not been altered in transit, for decoding encrypted text, or validating the identity of the security originator. NOTE: the security recipient is logically distinct from the application receiver.

Symmetric Key
See SECRET KEY.

Transformed Data
Transformed data is the encrypted data string resulting from application of an encryption algorithm to the span of characters beginning with the first character of the initialization vector and ending with the character preceding the segment delimiter of the last segment in the range of data to be secured.

3.2 Abbreviations

ASCII: American Standard Code for Information Interchange
CBC: Cipher Block Chaining
CFB: Cipher Feedback
DEA: Data Encryption Algorithm
EBCDIC: Extended Binary Coded Decimal Interchange Code
ECB: Electronic Code Book
IDA: Identity of Key for Authentication
IDE: Identity of Key for Encryption
IV: Initialization Vector
MAC: Message Authentication Code

4. Data Security Related Concepts

4.1 General

This section describes general cryptographic concepts as they apply to authentication, encryption, and assurances.

The models for authentication, encryption, and compression presented in this Section are those of ANSI X9.9, ANSI X9.23, and X9.32. These standards use the Data Encryption Algorithm (DEA) as described in ANSI X3.92 and the Modes of Operation of the DEA as defined in ANSI X3.106. This document makes provision for other standards -- including future ANSI or other standards -- by providing data structures for the use of other cryptographic algorithms, including asymmetric algorithms.

The companion document Cryptographic Service Message Transaction Set (815) deals with the management and distribution of symmetric keys, asymmetric keys, and certificates of authority.

The model for electronic signatures is based on the public key cryptographic standards work of ANSI X9F1, and the Secure Hash Algorithm (SHA) and the Digital Signature Algorithm (DSA) work of NIST that is contained in Federal Information Processing Standards 186 (FIPS 186). The approach taken is flexible enough to encompass other public key standards and de facto standards.

4.2 Authentication

Authentication is a technique used to:

• Verify the identity of the security originator of a message to the security recipient in order to detect spoofing or impersonation

• Verify the integrity of the message by detecting changes (modifications) in a message (including transmission errors) introduced between the security originator and the security recipient

• Protect a unique message identifier which is used to detect attempts at insertion, deletion, or replay of messages

The ANSI X9.9 standard employs ANSI X3.92 to compute a Message Authentication Code (MAC). The MAC is a cryptographically derived hash total that can be used to verify the security originator to the security recipient or protect the integrity of the applicable data.

Authentication is designed to provide protection for a message between the security originator and the security recipient. To provide that protection, the key used to perform the authentication must be known only by those two parties (or their authentication devices), and the message must not be modified in any way after the authentication process is performed by the security originator.

Authentication does not modify the text that is input to the process. The authenticated message can pass through any communications equipment that can handle the unauthenticated message. The receiving process must be able to reconstruct the original message from the data delivered by the communication equipment in order for the message to pass the checking process.

Basic requirements for a secured business interchange include the need to detect attempts at insertion, deletion, and replay of messages. This requirement can be satisfied by having the originating application place a combination of date and message identifier (such as a purchase order number) -- according to the requirements of ANSI X9.9 -- into the authenticated message so that the receiving application can uniquely identify each message sent. Then the security recipient can detect a repeated message by its repeated date and message identifier. Deleted messages can be detected by the originating application by the lack of an authenticated response (when one is used) or by the receiving application by reconciling the messages received against a list sent by the originating application in a separate authenticated message. Text inserted into the secured-body can be detected by the receiving application by the failure of the message to authenticate. The following diagram depicts the authentication model.

Figure 4.1 - Authentication Model

This model shows the computation of the MAC by the security originator (Party A). The computed MAC is appended to the message before transmission to the security recipient (Party B). A similar computation must be performed by the security recipient; the computed MAC must be compared with the received MAC to verify the security originator and to detect changes in the message. If the MACs compare successfully, Party B knows that the message has not been modified (providing data integrity), and knows that the message was authenticated by the security originator (providing verification of the security originator to the security recipient).

4.3 Encryption

The confidentiality of EDI encoded data is protected by the use of encryption. This standard provides a method for protecting the confidentiality of ASC X12 formatted data that is independent of the actual structure and the data content. In all cases, the structures defined in this standard apply.

Use of the encryption option of this standard does not provide detection of alteration of messages between the security originator and the security recipient. If encryption were used without authentication or assurance and an error occurs in transmission, the error may not be detected and the decrypted message may not be usable nor able to be processed. Authentication or assurance can be used to provide integrity while using encryption to provide confidentiality of the same data. When both authentication or assurances and encryption are used, the authentication or assurances are performed before encryption of the original plaintext data.

4.3.1 Assurances

Assurances, as defined in this standard, are a generalization of the concept of "electronic signature." The assurance originator expresses "business intent" by adding an assurance (one SxA segment and one SVA segment) to a transaction set or functional group that codifies the intent and computes a MAC or digital signature based on the text or the secured digest of the transaction set or group. The assurance recipient verifies the digital signature. Since the assurance originator is the only entity that could have generated the digital signature in a public key system, the assurance recipient can have certainty that expressed business intent is valid. The assurance provides for:

• Encoding of "business intent"

• Any text (e.g., signer's name, license number, etc.) desired by the signatorlito accompany the signature

• Date/time stamp

• Non-reputable signature

• Dis-embodied signature

4.3.2 Non-repudiation

Using a private-key/public-key approach, non-repudiation of origin of a message can be established since only the assurance originator can generate the signature. Any recipient that has access to the technology and that can verify the certificate chain, is able to verify the signature.

Non-repudiation of receipt is also supported by this standard. Using a private-key/public-key approach, a message recipient can generate an electronic signature value that will assure the message originator that the message was received by the intended party, without modification.

Non-repudiation is achieved since the process provides irrevocable proof, to a third party, that the security originator has access to the private key component. The strength of public key technology relies on the mathematical insolubility of the reverse process.

4.3.3 Supporting Services

Compression
Data compression takes a contiguous stream of characters and transforms the stream into a series of codes. If the compression algorithm is effective, the resulting stream of codes is smaller than the original text.

The theory of data compression is based on redundancy in the original text. For X12-encoded data, the repetition of segment identifiers in conjunction with separators, the recurrence of alpha and numerical substrings, and the frequency of common codes -- all add up to considerable redundancy in the ASCII encoding stream.

The various common data compression algorithms provide different coding methods for single and multiple character combinations that occur with different probabilities.

Modern compression techniques fall into several families: Shannon-Fano coding, Huffman coding, statistical modeling, and methods based on an adaptive dictionary. These techniques are often used for compressing files on bulletin boards or in modems that are able to perform compression/decompression "on the fly." If compression is used, it must be completed before the encryption process.

Security Error Reporting
While security products and algorithms provide a reliable and stable output, errors can occur. It is imperative that any security-related error be detected and reported immediately. A series of error codes and conditions have been defined to support this reporting requirement. It is possible to communicate these codes in the ASC X12 Functional Acknowledgment (997); however, it is recommended that the ASC X12 Secured Receipt or Acknowledgment (993) be the primary method for reporting security protocol errors.

4.3.4 Filtering of Encrypted or Compressed Data

The result of the encryption process is a pseudo-random binary string. Some communications systems will interpret some of the pseudo-random binary output as control characters or control sequences which may have a detrimental effect on transmission services (e.g., spurious XON/XOFF or EOF characters).

Filtering is a reversible process that converts the binary output from the encryption process to a coded character set output that does not contain control characters or sequences. The receiving process uses the inverse filtering process to convert the data back to the binary data so that it can be decrypted.

Filtering is performed after all other security processes are complete.

This process will normally increase the size of the message. ANSI X9.23 defines several optional filters that provide a tradeoff between character set flexibility and message expansion:

• The hexadecimal filter converts each byte of binary data into two hexadecimal characters (0..9, A..F) expressed in the character set of transmission. This filter works well with nearly all character sets, but it produces an expansion of 100%.

• The ASCII filter converts the binary data to a string of ASCII printable characters and normally produces an expansion of about 23%.

• The ASCII/Baudot filter converts the binary data to a string of characters belonging to both the ASCII and Baudot character sets and normally produces an expansion of about 86%.

This standard also allows the use of no filter or the use of a filter specified by mutual agreement among the options provided by the code set maintained by ASC X12.

4.4 Sequencing of Cryptographic Techniques

In practical situations, the users of this standard will choose combinations of features rather than just a single feature. The supported combinations of features, not including assurances, are specified in the codes for DE 990 - Security Type. All features are designed to be used in isolation or in any combination.

Authentication does not protect the confidentiality of the message because the information is interchanged in its plain text form. Message encryption can be used to provide confidentiality while using authentication to provide integrity protection of the same data. When both authentication and encryption are used, the authentication is performed before encryption of the original plain text data.

Where more than one service is selected at a specific level, the order of processing is:

• Before applying any security services, the data must first be translated into an EDI format

• Addition of one or more assurances

• Authentication

• Compression

• Encryption

• Filtering for data communications

When assurance segments (S4A and SVA) are used, they must be added to unsecured (not authenticated or encrypted) transactions. If a transaction set is received (with or without assurances) with encryption and/or authentication applied by the originator, the transaction set must be either decrypted or authenticated prior to the addition of any further assurances. Once any assurances have been added, the transaction set can be encrypted or authenticated prior to being forwarded to additional parties.

When applying security services at the functional group level, all security services at the transaction set level must be completed before applying security services at the functional group level.

The receiving organization processes the received message in the reverse order, starting with inverse filtering, followed by decryption, followed by decompression, validation of authentication and validation of the assurances. When processing inbound security services at the transaction set level, all security services except assurances at the functional group level must be removed before processing inbound security services at the transaction set level. (Note that to maintain the validity of the assurances associated with S3A, S4A assurances must not be removed before verification of the S3A assurances.) In this manner the receiving organization unwraps the EDI message by processing the security services and removing the S3S/S3E pairs from the message before processing the next security service.

5. ASC X12 Security Segment Specifications

5.1 General

Security services (authentication, encryption and assurances) are provided at two levels within ASC X12 in conjunction with the following envelopes:

• Functional Group (GS/GE envelope)

• Transaction Set (ST/SE envelope)

The Version/Release of the Security segments is independent of the Version/Release/Sub-release version identified in the Functional Group Header (GS). The Version/Release for the security structures is contained in the first data element of the S3A, S4A, S3S, & S4S segments. This version/release code indicates the specific version/release of the standard that is applicable to that security segment and the associated security trailer or security value segment. The same transaction set or functional group may have different version/releases of the security standard applied to it or there may be different version/releases of the security standard applied to multiple transaction sets or functional groups.

At each of these levels, authentication, encryption and assurances are each optional. Assurances are independent of authentication or encryption. In addition, any service used at one level is independent of a service used at the other level.

Assurances are applied before any other security processes (authentication, encryption, and compression). Therefore, the assurance segment (S3A or S4A) immediately follows the segment initiating the beginning of this level (GS or ST), and precedes any existing assurance segments (S3A or S4A). The Security Value (SVA) segment follows any existing Security Value (SVA) segments and precedes the segment terminating the level (GE or SE).

If encryption and/or authentication is provided, the security header segment (S3S or S4S) immediately follows the segment initiating the beginning of this level (GS or ST); the security trailer segment (S3E or S4E) precedes the segment terminating the level (GE or SE). If encryption and/or authentication at both levels is provided and if assurances are used at both levels, the sequence of segments, illustrating these levels, is:

ISA - Interchange Header

GS - Functional Group Header

S3S - Security Header Level 1

S3A - Assurance Header Level 1

ST - Transaction Set Header

S4S - Security Header Level 2

S4A - Assurance Header Level 2

(The Transaction Set Segments)

SVA - Security Value (Level 2)

S4E - Security Trailer Level 2

SE - Transaction Set Trailer

SVA - Security Value (Level 1)

S3E - Security Trailer Level 1

GE - Functional Group Trailer

IEA - Interchange Trailer

There is one exception to the segment placement defined above. The Secured Receipt or Acknowledgment (993) uses a unique sequencing of the assurance segments. The Secured Receipt or Acknowledgment (993) contains assurances for information not contained in the transaction set. The transaction set designers believed that using the S4A/SVA pair standard placement would mislead implementers. Therefore, to provide greater clarity, the S4A/SVA pair were placed together just prior to the SE segment.

5.2 Standard Structures for Security Segments

5.2.1 Segment Constructs in Backus-Naur Form (BNF)

The security related segments are constructed as follows:

5.2.2 General

In this Section, the principles of the standard structures that are implemented at the various levels are established. Thus, in the description of this Section, the generic "SxS", "SxE", and "SxA" segments are referenced. Specifications for the interchange segments are provided in the segment directory.

Security at each potential level is optional and is independent of security at other levels.

The security header (SxS, x = 3 or 4), trailer (SxE), and assurance (SxA) segments are defined for the two levels (functional group and transaction set) using identical formats differing only in the naming of the segments and the reference designators.

The same key shall not be used for more than one function (i.e., authentication or encryption) at any one level. A key used to provide protection at one level shall not intentionally be used at the other level for the same or a different purpose.

When used, the security header segment (generic SxS) is placed immediately after the first segment of the authenticated group of segments. The security header segment identifies which security services are to be used and identifies authentication and encryption keys to be used. The format of the SxS can be found in the segment dictionary.

If the SxS segment is used at the beginning of a functional group or transaction set, the security trailer segment (SxE) precedes the last segment of the same functional group or transaction set.

The security trailer segment is used to end the authentication and encryption process initiated by the corresponding security header segment. SxE01 is the message authentication code (MAC) or hash generated by applying the authentication algorithm against the designated segments.

If one or more assurances are used at either level, one SxA segment and one SVA segment are added. The first Assurance (SxA) and any subsequent Assurances are placed immediately after the first segment of the assured group of segments (GS or ST) and before any previous SxAs.

If the SxA segment is used at the beginning of a functional group or transaction set, the Security Value (SVA) will immediately precede the last segment of the same functional group or transaction set. The SVA for any additional assurances will follow any previous SVAs and precede the last segment of the group or transaction set (GE or SE).

The preparation of ASC X12 text and formatting of security header and trailer segments (see Section 5.1) consists of:

1. Determining whether a transaction set or functional group will be authenticated, encrypted or assured.

2. Inserting an SxA segment after the first segment of the group or transaction set (GS or ST) that will be assured and before the SxA of the last assurance at the same level, if present.

3. Inserting an SVA segment before the last segment of the group or transaction set (GE or SE) and after the SVA of the last assurance at the same level, if present.

4. Inserting the SxS segment after the first segment of the group of transaction set (GS or ST) that will be authenticated or encrypted and before any Assurances (SxA) if present. The SxE segment is inserted after any Security Values (SVA), if present, and before the last segment of the group or transaction set (GE or SE).

When the S4S and S4E segments are added, the segment count in the SE segment is increased by 2. When the S4A and SVA segments are added, the segment count in the SE segment is increased by 2. When S3S, S3E, S3A or SVA segments are added to the functional group, the count of transaction sets in the group is not changed.

The scope of the authentication process is defined as follows:

• Authentication begins with the first character of the segments designated for authentication (i.e., the first Character of the segment preceding the "SxS" segment).

• If encryption is also to be performed, the authentication process is performed through the SxS09 element and then continues with the segment terminator of the SxS segment (i.e., as if the Length of Data segment, the Initialization Vector element, and their preceding segment separators were not present).

• Authentication ends with and includes the data element separator preceding the hash code.

The scope of the compression process is defined as follows:

• Compression starts with the first character of the segment that follows the SxS segment.

• Compression ends with the last character of the segment that precedes the SxE segment (and does not include the segment separator).

The scope of the encryption process is defined as follows:

• Encryption begins with the Initialization Vector field (SxS11).

• The Initialization Vector (IV) is encrypted using Electronic Code Book (ECB). A new IV shall be used for each message and shall not be intentionally reused. Text following the IV is encrypted using the mode specified in the Encryption Service Code (SxS09).

• Encryption ends with the last character before the segment terminator of the segment preceding SxE.

• Filtering is applied to the encrypted IV and, optionally, to the encrypted data.

• When present, the Length of Data data element counts the number of octets in the encrypted and filtered IV and data.

• When certain block ciphers (i.e., CBC mode of DES) are used for encryption, the plaintext data is padded to a multiple of the block size octets by adding text consisting of 0 to 7 ASCII-zeroes followed by a length value consisting of one ASCII character with value ranging from "1" to "8" that specifies the number of octets used in the padding. This padding meets the requirements of ANSI X9.23 and is completely deterministic. Because of the padding, the pre-encrypted text will always be a multiple of the block size prior to filtering and thus fit any block-oriented encryption mode of operation. The padding is added immediately prior to encryption and is removed by the decryption process; it is not included in the calculation of the hash that is computed prior to encryption.

The scope of the assurance process is defined as follows:

• The scope of each assurance is defined for that assurance by the contents of the Domain of Computation of Assurance Digest (SxA04) data element in the SxA segment.

5.3 Functional Group Security (GS/GE, Level 1)

Assurances are applied before any other security processes (authentication, encryption, and compression). Therefore, the assurance segment (S3A) immediately follows the segment initiating the beginning of this level (GS), and precedes any existing assurance segments (S3A). The Security Value (SVA) segment follows any existing Security Value (SVA) segments and precedes the segment terminating the level (GE).

Encryption and/or authentication is available for individual functional groups through the use of the S3S and S3E segments. Both the S3S and S3E segments can be present or absent for any functional group. Security (authentication and/or encryption) at this level is optional and is independent of security at any other level.

If functional group level security is used, the key used for authentication and the key used for encryption shall be different, and the keys shall not be used for any other security purpose. Separate functional groups, within the same interchange or in separate interchanges, may use the authentication key or the encryption key used for the same purpose in other functional groups.

Definitions of security segments and data elements are given in the segment and data dictionaries.

The placement of security segments is defined below.

• The S3A segment immediately follows the GS segment.

• The S3S segment immediately follows the GS segment and is inserted immediately before any S3A or S3S segments, if present.

• The S3E segment precedes the GE segment and is inserted immediately after any SVA or S3E segments, if present.

The scope of security segments is defined as given below.

• Authentication begins with the first character of the functional group (the "G" of GS*.....).

• Authentication ends with and includes the data element separator preceding the hash code.

• Compression begins with the first character of the segment following the S3S segment (i.e., the first character of the first enclosed transaction set).

• Compression ends with the last character before the segment terminator of the segment preceding the S3E.

• Encryption begins with the first character of the Initialization Vector (S3S11).

• Encryption ends with the last character before the segment terminator of the segment preceding S3E.

• Assurance segments have a scope defined by the code in S3A04.

5.4 Transaction Set Security (ST/SE, Level 2)

Assurances are applied before any other security processes (authentication, encryption, and compression). Therefore, the assurance segment (S4A) immediately follows the segment initiating the beginning of this level (ST), and precedes any existing assurance segments (S4A). The Security Value (SVA) segment follows any existing Security Value (SVA) segments and precedes the segment terminating the level (SE).

Encryption and/or authentication is available for individual transaction sets through the use of the S4S and S4E segments. Both the S4S and S4E segments can be present or absent for any transaction set. Security (authentication and/or encryption) at this level is optional and is independent of security at any other level.

If transaction set level security is used, the key used for authentication and the key used for encryption shall be different, and the keys shall not be used for any other security purpose. Separate transaction sets, within the same functional group or in separate functional groups or interchanges, may use the authentication key or the encryption key used for the same purpose in other transaction sets.

Definitions of security segments and data elements are contained in the segment and data element dictionaries.

The placement of security segments is defined below.

• The S4A segment immediately follows the ST segment, except when used in the Secured Receipt or Acknowledgment (993). In the Secured Receipt or Acknowledgment (993), the S4A will immediately precede the SVA segment.

• The S4S segment immediately follows the ST segment and is inserted immediately before any S4A or S4S segments, if present.

• The S4E segment precedes the SE segment and is inserted immediately after any SVA or S4E segments, if present.

The scope of security segments is defined as given below.

• Authentication begins with the first character of the transaction set (the "S" of ST*.....).

• Authentication ends with and includes the data element separator preceding the hash code.

• Compression begins with the first character of the segment following the S4S segment (i.e., the first character of the transaction set body).

• Compression ends with the last character before the segment terminator of the segment preceding the S4E.

• Encryption begins with the first character of the Initialization Vector (S4S11).

• Encryption ends with and includes the last character before the segment terminator of the segment preceding S4E.

• Assurance segments have a scope defined by the code in S4A04.

6. Auditing and Responding to Secured ASC X12 Data

Since the security structures are embedded in the ASC X12 structures, the responses will be found embedded in the response to a group of transactions, the Functional Acknowledgment Transaction Set (997).

These security structures are an integral part of the management of the ASC X12 EDI environment. When an audit journal is required, it may be required for a variety of EDI management purposes. This Section also attempts to reconcile these disparate purposes.

Only a single 997 response is allowed for a functional group, and it must report on the syntactic integrity of the entire received group of transaction sets.

A. Appendix

This Appendix is not part of the standard but is included for information only.

The example shows authentication and the use of the assurance segment -- with authentication applied at both levels and multiple assurances segments ("signatures") on the first transaction at transaction set level only. The security recipient for the transaction set (shown in the S4S segment) in this example is different from the security recipient of the functional group (shown in the S3S segment). The original transaction was signed by the original preparer of the ASC X12 message (code "PRP" indicates "preparer"), but the second signature was applied by a subsequent handling party (code "ASG" indicates authorizer).

The integrity indicated by the functional group hash would have been calculated after the application of this second signature.

NOTE: Cryptographic values are for explanation purposes only and do not represent real output of the stated cryptographic algorithms.

Many other combinations are possible, including authentication at one level (S3S or S4S) and other combinations of the same or different security originator or security recipient names.

The actual MACs generated by the security originator are dependent on the values of the cryptographic keys corresponding to the key names KEY_ONE and KEY_TWO. The values of the cryptographic keys are known only to the security originator and the security recipient. Only the names of the keys are sent in the above interchange.

If encryption in the CBC mode was applied to the second transaction set in the example above in addition to authentication, the S4S segment would have the following appended to it immediately prior to encryption:

*KEY_THREE*20*192*8 octets of IV

and the TDS segment in the encrypted form only would be:

TDS*511100000008

where "00000008" is the padding (seven ASCII zeroes followed by a total length of padding of eight). This padding is removed after the decryption process.

Following encryption, the length of the ciphertext data is placed in the LOD field. For this example, if filtration is not used, the value placed in the LOD field is "192" consisting of the sum of the following:

• Length of encrypted IV (always eight)

• Length of plain text segments including segment terminator character (176). The count includes the segment terminator of the S4S segment (encrypted) but not the segment terminator of the TDS segment (not encrypted).

• Length of padding (eight, in this example)

If filtration is used, the LOD is the length of the filtered, encrypted text and thus not necessarily a multiple of eight octets. The hash at the transaction set level (in S4S01) is not affected by the encryption of the transaction set. The hash at the functional group level (in S3S01) would be affected since the computation is performed on the transaction set as enveloped, i.e., as both authenticated and encrypted.