Standards for Technology in Automotive Retail

 Home -  News Feed 

Chapter 10. Message Level Security

Table of Contents

10.1. Requirements
10.1.1. Applying STAR Transport Requirements to Message-Level Security
10.1.2. Using Digital Certificates for Identification and Authentication
10.1.3. Using Username/Password for Identification and Authentication
10.1.4. Message-Level Source, Target and System Authentication
10.2. Discussions: ebMS Message-Level Security
10.2.1. Digtally Signing a STAR ebMS Message
10.2.2. STAR ebMS Message-Level Encryption
10.3. Discussions: Web Services Message-Level Security
10.3.1. Web Services Authentication Options
10.3.2. Digital Signature
10.3.3. Username/Password Hash
10.3.4. Username/Password Clear-text over HTTPS
10.3.5. Binary Token Shared Secret
10.3.6. Security Assertion Markup Language (SAML)
10.3.7. Web Services Message-Level Privacy with Data Encryption
10.4. Discussions: Digital Certificate Format
10.5. Decisions

10.1. Requirements

10.1.1. Applying STAR Transport Requirements to Message-Level Security

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

Message senders in upstream automotive typically assume one of three key roles; Dealership or Dealership Management System, Intermediary and OEM. STAR Transport does not prescribe how a receiver should view these business relationships. The Guidelines do describe a limited set of Security technologies and methods to be applied directly to a message in transit. In other words, STAR defines Identity and Authentication mechanics to enable a sender to authorize a transaction, but STAR does not prescribe how the message receiver actually decides whether a sender is authorized or not to execute a service or query for information.

A receiver must identify a sender based on:

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



  • 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 does not take into account security data located in the SOAP body or BOD payload of a message, all Message-Level security data is contained within SOAP Message Headers.

10.1.2. Using Digital Certificates for Identification and Authentication

STAR Messages MAY be Digitally Signed using Digital Certificates as a basis of the signature. STAR recommends that Digital Certificates not be passed in the message itself. If present in a message, a Digital Certificate MUST be protected through Data Encryption. If the parties agree, a reference to a known certificate, such as a Distinguished Name, MAY be passed in a message.

By signing a message, the sender is making the statement "I am the subject represented by the Digital Certificate and this is a message from me". In other words, the sender's Identity can be determined by the fact the sender holds the private key associated with a specific Digital Certificate and the sender has digitally signed the message using that private key. STAR allows for the use of self-signed certificates. The use of self-signed certificates provides adequate security in most use cases in which STAR transactions will occur. If a trading partner needs added security above and beyond the security provided by self-signed certificates, they may use a 3rd party root CA. Using a root CA can provide an added level of assurance that the party is who they say they are, but at significant cost to the trading partners involved.

10.1.3. Using Username/Password for Identification and Authentication

STAR Messages MAY include a Username in the SOAP Message Headers. If present, a Username / Password combination MUST be used to Authenticate the message sender.

Senders MUST take steps to ensure the protection of passwords. If a Password is sent in the message, it MUST be obfuscated using data encryption or some other method that makes the Password unreadable to any party other than the intended recipient. If Password is not obfuscated at the message level, it must be encrypted at the Transfer Infrastructure-Level using SSL.

If the two parties agree, a hash of the Password MAY be passed in place of the Password itself.

Parts of STAR messages MAY be encrypted using XMLEncryption. Typically, a sender uses the Public Key of the receiver (based on the receivers Digital Certificate) to generate an encrypted Symmetric Key that is then used to encrypt parts of the message. When received, the receiver processes the message, which uses its Private Key to decrypt the Symmetric Key, and uses the Symmetric key to decrypt the message.

Within the message Header elements, WS-Security 2004 elements MAY be used to help a receiver determine what parts of the message are encrypted.

10.1.4. Message-Level Source, Target and System Authentication

System, Source and Target Authentication are commonly associated with Transfer Infrastructure-Level security. Typically, HTTP/S is used in conjunction with infrastructure components such as Firewalls and LDAP Directories to establish the Identity of the Systems involved in messaging. STAR does not prescribe any methods for these features at the Message-Level. Implementations of these features are discussed in detail under Infrastructure-Level Security.