| Standards for Technology in Automotive Retail |
| Home - News Feed

2.3. Security
Prev | Chapter 2. Executive Summaries | Next

## 2.3. Security

Section two outlines the necessary steps and requirements needed to successfully implement your network to work with STAR standards.

Chapter 8, Security

STAR defines eight security requirements:

- Business Authentication

- Party Authentication

- Privacy/Confidentiality

- Source and Target Authentication

- Source Only Authentication

- System Authentication

- Unique Party Identification

When two parties exchange digital business data in the form of a message, key questions related to the above requirements must be asked and answered by each party to assure that the business transaction is secure. A detailed list is included in the chapter.

STAR recommends Message-Level security be applied where applicable especially in situations where there is monetary and legal risk. The key benefit of Message-Level security is the ability to route secure messages through multiple parties, endpoints, applications and or transfer protocols. In lieu of Message-Level security, STAR recommends Infrastructure-Level Security such as SSL. If parties agree, security may be applied at both Message-Level and Transfer Infrastructure-Level. Both Message Level Security and Infrastructure-Level Security are discussed in depth in individual chapters.

Chapter 9, Infrastructure Level Security

Internet Secure Channel Infrastructure provides a mechanism for STAR trading partners to exchange messages over the public Internet while maintaining the following security requirements:

- Business Authentication

- Party Authentication

- Privacy/Confidentiality

- Source and Target Authentication

- Source Only Authentication

- System Authentication

- Unique Party Identification

Infrastructure-Level Security can be applied equally to both STAR Web Services and STAR ebMS messages and is adequate for most business communications. Message Level security is usually only necessary for messages that contain information involving substantial monetary or legal risk.

The STAR recommended and most common secure channel Infrastructure is SSL over HTTP. In this type of transaction a Digital Certificate is passed between the sender and the receiver to verify that each partner is a trusted party and to perform required authentications. All SSL traffic uses very secure encryption keys to enable privacy and confidentiality.

Virtual Private Networks provide another Infrastructure-Level Security alternative. The concept of a VPN is to provide a secure channel that allows messages to be transported in a safe “tunnel” that may be running over public networks. However, A VPN requires that both the Sender and Receiver install and maintain similar proprietary software or messaging software packages based on a common standard such as IPSec.

Chapter 10, Message Level Security

Message Level Security can be defined as information carried in the message itself, which enables Privacy, Identification and Authentication.

All Message-Level security data is contained within SOAP Message Headers. When message level security is applied a receiver must identify a sender based on:

- The To Party Name/URL as contained in the message SOAP Header elements OR

- A security token which may be contained in SOAP Headers or passed out of band

A receiver must authenticate a sender based on:

- A security token which may be contained in SOAP Headers or passed out of band

STAR currently allows for two types of security tokens:

- Digital Certificates

- Username/Password

STAR partners using digital certificates will have to agree on the subset of formats and extensions. With STAR ebMS the certificate format should be referenced in the CPA. With STAR Web Services the certificate format should be agreed upon out-of-band. Digital Signatures applied to a message must be in full compliance with [XMLDSIG], [WS-Security] and [WS-Security Addendum]. To aid interoperability and provide stronger authentication, certificates may be self signed; self issued or obtained through well known third party Certificate Authorities.

If a Password is sent in the message, it must use encryption or some other method that makes the Password unreadable to any party other than the intended recipient. If Password is not encrypted at the message level, it must be encrypted at the Transfer Infrastructure-Level using SSL. However, if the two parties agree, a hash of the Password may be passed in place of the Password itself. WS-Security 2004 elements MAY be used to help a receiver determine what parts of the message are encrypted.

STAR Transport recommends the use of [XMLEncryption] or [SMIME] based encryption for ebMS Messages. With STAR Web Services It is optional for a specific message exchange to be encrypted, but if encryption is applied to a message the message format MUST be in full compliance with [XMLEncryption], [WS-Security].

STAR requires that digital certificate formats are compliant to X.509 v3 format and recommends limiting extensions to basic constraints. If an X.509 v3 certificate is exported for exchange with a partner, it is recommended that it be exported with its entire trust chain.

STAR Transport solutions should be able to import the following certificate file formats: .p7b .p7c .pfx .cer. However, the .cer format is not recommended except for self-signed X.509 v3 certificates.

Prev | Up | Next
2.2. Message Handling | Home | 2.4. Management and Functionality