OFTP Security
The latest step in the evolution of the OFTP protocol entails the addition of full security.
In theory, any method of communication is open to the threat of infiltration, either by amateurs or professionals. Even ISDN lines can be tapped if a determined party obtains the necessary information to do so.
However, it is the increasing use of TCP/IP communications that has led to the demand for a means of maintaining the security of the data being exchanged. In particular, the automotive industry requires that ENGDAT data, containing highly sensitive design documents, should be exchanged in a totally secure manner.
OFTP in its original form offered no real security. User IDs and passwords were utilised but, although useful for identification purposes, were human-readable and thus open to possible manipulation.
To overcome this failing, the existing OFTP protocol has been reviewed and extended to rise to this security challenge, resulting in the release of OFTP version 1.5. A handful of minor programmatic changes have been made, including the addition of the following:
- Authentication protocol data units
- File encryption data unit header
- Some additional ESID header codes
- New version level in the SSID
New sign-on commands
There has also been an extension to the existing OFTP sign-on commands with several new challenge/response data units, as shown below.
These new OFTP commands cover the exchange of extra introductory details. If either party wishes to end the session because they are not satisfied with the contents of any of these commands, they will use the ESID command to do so.
| SECD |
Security Change Direction |
Contains a single character “N”, to indicate this is an SECD command. |
| AUCH |
Authentication Challenge |
Contains a single character “A”, to indicate this is an AUCH command, and a 16 digit random number uniquely generated each time an AUCH is sent. |
| AURP |
Authentication Response |
Contains a single character “S”, to indicate this is an AURP command, and a variable length field that is the challenge from the AUCH signed with the private key of the sender of the AURP and encoded into a CMS/PKCS #7 message. |
The requestor of the session sends Security Change Direction (SECD) to which the responder replies with an Authentication Challenge (AUCH). The AUCH contains a randomly generated 16-byte number so that it is unique each time. Using his private key, the requestor returns the signed challenge in an Authentication Response (AURP). Using the requestor's public key, the responder verifies the requestor's identity and replies with an Security Change Direction (SECD), beginning the complementary process of verifying the responder to the requestor.
PKI security
OFTP security makes full use of the encryption technologies provided by PKI security to meet the security objectives of:
- Authentication – the process of proving one’s identity
- Confidentiality – ensuring that nobody can read the message except for the intended recipient
- Integrity – assuring the recipient that the received message has not been altered in any way from the original
- Non-Repudiation – a mechanism to prove that the sender/recipient really sent/received a message
Session Authentication is achieved during the process of exchanging the OFTP security challenges and responses. Each partner takes it in turn to send a piece of plain text (a human-readable 16-byte random number) to their partner.
This is then signed by their partner’s private key and returned to the sender, where the original sender then decrypts it using their partner’s public key.
If the plain text is identical to that sent originally, the originator can be confident that their partner is who they claim to be.
If either partner is not satisfied about the identity of the other, they will end the session by sending an ESID command containing a code 16 to indicate that session authentication failed (code 16 indicates that an incorrect challenge was received).
Authentication of file origin is ensured by use of a digital signature.
Encryption of the file ensures Confidentiality is achieved.
Integrity is ensured via the use of a message digest and a signature.
Non-Repudiation is achieved via the signing and encryption of the EERP that is returned to the sender to indicate receipt of the file.
Security levels
There are 2 different levels of security – Session security and File security – and it is possible to implement one without the other.
Session security, which will only be available for TCP/IP communications, is achieved using SSL (Secure Socket Layer). SSL is the most common form of Internet security and is used in particular for HTTPS transactions over the Internet.
File security involves the encryption of the file itself, as described in the section on PKI security.
To avoid the use of smart cards and HSMs, private key certificates will be held on the user’s machine in a certificate store.