S-63 IHO Data Protection Scheme

Back to:	CIRM Knowledge Base
Last update:	October 2020
Page completeness level:	Complete

Introduction

Special Publication S-63, the IHO Data Protection Scheme, describes the recommended standard for the protection of ENC information. It defines security constructs and operating procedures that must be followed to ensure that the data protection scheme is operated correctly and to provide specifications that allow participants to build S-63 compliant systems and distribute data in a secure and commercially viable manner.

Definitions

Blowfish	Encryption algorithm used by the protection scheme
Cell Key	Key used to produce encrypted ENC, and required to decrypt the encrypted ENC information.
Cell Permit	Encrypted form of Cell key, created specifically for a particular user.
Data Client	Term used to represent an end-user receiving the encrypted ENC information. The Data Client will be using a software application (e.g. ECDIS) to perform many of the operations detailed within the scheme. Typically, an ECDIS user.
Data Server	Term used to represent an organisation producing encrypted ENCs or issuing Cell Permits to end-users.
M_ID	The unique identifier assigned by the SA to each manufacture. Data Servers use this to identify which M_KEY to use when decrypting the Userpermit.
M_KEY	ECDIS manufacturer’s unique identification key provided by the Scheme Administrator to the OEM. It is used by OEMs to encrypt the HW_ID when creating a userpermit.
HW_ID	The unique identifier assigned by an OEM to each implementation of their system. This value is encrypted using the OEM’s unique M_KEY and supplied to the data client as a userpermit. This method allows data clients to purchase licences to decrypt ENC cells.
SA	Scheme Administrator
SHA-1	Secure Hash Algorithm
SSK	Self Signed Key (Self Signed Certificate File)
User Permit	Encrypted form of HW-ID uniquely identifiying the ECDIS system

General description

S-63 specifies a method of securing ENC information and maintaining the integrity of an ENC service with multiple data services serving a large customer base. The purpose of data protection is threefold:

1. Piracy Protection: To prevent unauthorised use of data by encrypting the ENC information
2. Selective Access: To restrict access to ENC information to only those cells that a customer has been licenced for
3. Authentication: To provide assurance that the ENC data has come from approved sources

Piracy protection and selective access are achieved by encrypting the ENC information and providing cell permits to decrypt them. Data Servers will encrypt ENC data provided by producer nations before supplying it to the Data Client. The encrypted ENC is then decrypted by the ECDIS prior to being reformatted and imported into the systems SENC. Authentication is provided by means of digital signatures within the data.

The scheme does not specifically address how ENC or SENC information can be protected once it is within an end-user application. This is the responsibility of the OEMs.

The scheme allows for the mass distribution of encrypted ENCs on hard media (e.g. CD-ROM or DVD) and can be accessed and used by all customers with a valid licence containing a set of permits. Selective access to individual cells is supported by providing users with a licenced set of permits containing the encrypted cell keys. This licence is created using a unique hardware identifier of the system and is unique to each Data Client. Consequently licences cannot be exchanged between individual Data Clients.

The scheme uses a compression algorithm to reduce the size of the dataset. Unencrypted ENC data contains many repeating patterns of information, e.g. coordinate information. Compression is therefore always applied before the ENC information is encrypted and uncompressed after the decryption on the data client system (normally an ECDIS).

Participants in the Scheme

The Scheme Administrator (SA) is solely responsible for maintaining and coordinating the scheme. The SA role is operated by The International Hydrographic Bureau (IHB), as secretariat of the IHO, on behalf of the IHO member states. The SA is responsible for controlling membership of the scheme and ensuring that all participants operate according to defined procedures. The SA maintains the top level digital certificate used to operate the S- 63 Data Protection Scheme and is the only body that can certify the identity of the other participants of the scheme.

Data Servers are responsible for the encrypting and signing ENC data in compliance with the procedures and processes defined in the scheme. Data Servers issue ENC licences (permits) so that Data Clients, with valid user permits, can decrypt ENC data. Data Servers will use the M_KEY and HW_ID information, as supplied by the SA, to issue encrypted ENC cell keys to each specific installation. Hydrographic Offices, Value Added Resellers and RENC organisations are examples of Data Servers.

Data Clients are the end users of ENC information and will receive protected information from the Data Servers. The Data Client’s software application (OEM System) is responsible for authenticating the ENC digital signatures and decrypting the ENC information in compliance with the procedures defined in the scheme.

OEMs subscribing to the IHO S-63 DPS must build a software application according to S-63's specifications and self-verify and validate it according to the terms mandated by the SA. S-63 contains test data for the verification and validation of OEM applications. The SA will provide successful OEM applicants with their own unique manufacturer key and identification (M_KEY and M_ID). The manufacturer must provide a secure mechanism within their software systems for uniquely identifying each end user installation. The scheme requires each installation to have a unique hardware identifier (HW_ID). The software application will be able to decrypt the cell keys using the HW_ID stored in either the hard lock or soft lock devices attached to or programmed within the application to subsequently decrypt and uncompress the ENC data. The CRC value contained within the ENC can then be verified to establish the integrity of the underlying S57 data.

Data compression

ENC data responds well to compression with reductions in size of between 30% and 60%, reducing greatly the cost of transfer of ENC data to its final destination. Only the ENC files (base and update) are compressed. The ENC files are always compressed before they are encrypted as the effectiveness of any compression algorithm relies on the existence of structured data contents.

The security scheme uses the ZIP algorithm to compress and uncompress ENC data.

Data encryption

What data is encrypted?

The scheme encrypts the complete content of the ENC Base or Update data files using one encryption algorithm. Other information within the Scheme that is encrypted includes the OEM System HW_ID which is encrypted and provided to the Data Client in the form of a userpermit.

The cell keys used to encrypt the ENC data files are themselves encrypted by the Data Server and supplied to Data Clients as cell permits.

How is it encrypted?

Each single ENC cell file is encrypted using a unique Cell Key. The same Cell Key is used to encrypt all updates issued for the cell. The scheme however, allows for the cell keys to be incremented and changed at the discretion of the Data Server. The Cell Keys are delivered to Data Clients in the form of cell permits.

• The ENC information (base cells and updates) are encrypted using a 40-bit key.
• The Userpermit and the Cell permit contents are encrypted using a 48-bit key.
• The scheme encrypts all information referenced above using the Blowfish algorithm, a block cipher algorithm that operates on 64 bit (8 byte) quantities.

Data licensing

Introduction

Data Clients do not buy ENC data but are licenced to use it. Licensing is the method that Data Servers use to give Data Clients selective access to up-to-date ENC cells for a given period of time. To operate the scheme effectively there must be a means where Data Client systems can unlock the encrypted ENC cells. To unlock the data the Data Clients system must have access to the cell keys that were used to encrypt the ENC cells. These keys are supplied to the Data Client, encrypted, in a permit file containing a set of cell permits. It is these cell permits that contain the encryption keys.

To make each set of cell permits exclusive the cell keys must be encrypted using something that is unique to the Data Clients system. OEMs assign a unique identifier (HW_ID) to each of their systems and provide an encrypted copy of this, in the form of a userpermit, to each Data Client. The HW_ID is stored in the userpermit encrypted.

OEMs encrypt the HW_ID with their own unique manufacturer key (M_KEY) so that a HW_ID cannot be duplicated by another manufacturer. Data Servers have access to the OEM M_KEYs and can therefore decrypt the HW_ID stored in the userpermit. Data Servers encrypt their cell keys with the manufacturers HW_ID when producing a set of cell permits. This makes them unique to the Data Client and as such not transferable between Data Client systems.

The Userpermit

The userpermit is created by OEMs and supplied to Data Clients as part of their system so that they can obtain the necessary access to encrypted ENCs from Data Servers.

All Data Clients with systems capable of using data, protected with the S-63 scheme, must have a unique hardware identification (HW_ID) built into their end-user system. Such a HW_ID is often implemented as a dongle or by other means ensuring a unique identification for each installation.

The HW_ID is unknown to the Data Client, but the OEM will provide a userpermit that is an encrypted version of the HW_ID and unique to the Data Client’s system. The userpermit is created by taking the assigned HW_ID and encrypting it with the manufacturer key (M_KEY). The CRC32 algorithm is run on the encrypted HW_ID and the result appended to it. Finally the manufacturer attaches their assigned manufacturer identifier (M_ID) to the end of the resultant string. The M_KEY and M_ID values are supplied by the SA and are unique to each manufacturer providing S-63 compliant systems.

The Data Client gains access to S-63 encrypted ENCs by supplying this userpermit to the Data Server who can then issue Cell Permits specific to it. Since the userpermit contains the manufacturers unique M_ID this can be used by Data Servers to identify which M_KEY to use to decrypt it. The M_ID is the last four characters of the Userpermit. A list of the manufacturer M_KEY and M_ID values is issued and updated by the SA to all Data Servers subscribing to the scheme. This list will be updated periodically as new OEMs join the scheme.

The Cell Permit

To decrypt an ENC cell the Data Client must have access to the encryption key used to encrypt it. Since the encryption keys are only known to the Data Server there needs to be a means of delivering this information to Data Clients in a protected manner. This information is supplied by the Data Server (e.g. RENC or VAR) to the Data Client in an encrypted form known as a cell permit. A single file is provided to deliver the cell permit and is named PERMIT.TXT (see section 4.3.1). This file may contain several cell permits based on the ENC coverage required by the Data Client.

The PERMIT.TXT file will be delivered either on hard media or using online services in accordance with the Data Servers operating procedures. These procedures will be made available to Data Clients when purchasing a licence. Each cell permit record also contains additional fields that are supplied to assist OEM systems to manage the Data Clients licence and permit files from multiple Data Servers.

Data Clients can obtain a licence to access ENCs by supplying the Data Server with their unique userpermit. Data Servers can then extract the HW_ID from userpermit, using the Data Client’s M_KEY, and create client specific cell permits based on this value.

Since Cell Permits are issued for a specific HW_ID they are consequently not transferable between installations (Data Client Systems). This method of linking the permit to the installation supports the production of generically encrypted CDs which can be distributed to all Data Clients subscribing to a service.

The Data Clients system decrypts the Cell Permit using the assigned HW_ID stored securely by hardware or software means. The decrypted cell keys can then be used by the system to decrypt the ENC cell. Since several Data Servers can make permit files for ENCs in their service, it is the responsibility of the Data Client system to manage permit files from several Data Servers.

Data authentication

Introduction to Data Authentication and Integrity Checking

The digital signature technique used in the S-63 scheme uses a standard algorithm and key exchange mechanism widely used. S63 digital signatures use asymmetric public key algorithms within a PKI-like infrastructure scheme to unbreakably bind a data file with the identity of the issuer.

The scheme relies on asymmetric encryption of a checksum of a data file. By verifying the signature against the issuer’s public key, and also verifying the issuer’s public key against a top level identity the user is assured of the signer’s identity.

The scheme can be considered to have three distinct phases:

1. A Scheme Administrator (SA) verifies the identity of a supplier of ENC information and provides the supplier with data to allow them to sign ENC data
2. A Data Server (e.g. RENC or VAR) issues ENC data signed with their identity (and its verification by the SA)
3. The subsequent verification by the Data Client of the Data Server’s identity (by its association with the SA) and the integrity of the ENC data

ENC authentication process

1. The Data Server’s Public Key and Self Signed Key (SSK) File are sent to the SA for validation when applying to join the IHO S-63 Data Protection Scheme
2. If accepted the SA signs the Data Server’s SSK with its own private key to produce a SA signed Data Server Certificate which is then returned to the Data Server
3. The SA Public Key is widely distributed and installed indepenently in OEM systems
4. SA Public and Private Key pairs must be different from all other Data Servers
5. All Data Server Public and Private Keys must be unique to each other and the SA

Data authentication and integrity checking

If an ECDIS is using the method depicted above, and if the SA Key Pair is different from the Data Server key pair, then it is able to authenticate and validate ENCs from Data Server 2 (or any other Data Server in the scheme) using the same SA public key.

1. Authentication : The ECDIS uses the SA public key, previously installed indepenantly of the CD, to check the certificate part of the signature file to confirm that the supplier's public key

in the certificate is valid. That is, the Data Server is a bona fide member of the scheme

1. Integrity Check: The ECDIS uses the public key from the certificate to check the signature of the ENC cell (data) file.

SA verficiaton

The ECDIS needs to be able to verify that the ENCs are from a bona fide source. It does this by ensuring that the data server’s public key provided within the ENC signature files can be validated against the SA’s public key.

The SA provides certificates to each data server in the scheme; each certificate is unique, the SA only has to do this task once for each data server when they join the scheme. To obtain a certificate, data servers generate a key pair and provide the SA with their public key (as a self signed certificate); the SA (using their existing key pair) uses their private key to sign the data server’s public key. The resulting certificate contains a signature of the supplier’s public key. This certificate is then included within all ENC cells’ and updates’ signature files.

The SA makes their own public key widely known to the ECDIS community and OEMs should provide a means for the user to load this independently of the data.

Data integrity

After the source of the ENC exchange set has been authenticated the ECDIS then checks data integrity by validating the signature file provided for each ENC by the data server.

The data server creates a signature file for each cell which consists of the following two parts:

• The signature of the dataset [which is created using the data server’s private key, half of the data server key pair (in essence this is an encrypted checksum of the data) and is different for each cell]
• Their Data Server certificate (which remains constant)

The ECDIS uses the data server’s public key that is included in the certificate to validate the data file signature (it decodes this data file signature and compares the checksum against the ENC cell). If this validation check is successful then it proves that the ENC has not been corrupted in any way and that the identity of the Data Server within the cell signatures is validated by the SA.

Digital certificates (SA authentication)

Certificates are digital files issued by a certification authority. They bind a specific public key together with other information to an individual or organisation. Certificates help prevent someone from using a fake public key to impersonate someone else. The scheme uses a chain of certificates, each one certifying the previous one until all parties are confident as to the identities in question. The SA certificate used by the IHO will be a self signed certificate and is the root certificate for the scheme.

The SA will issue a digital certificate to all approved Data Servers by signing the Data Server’s verified public key file.

Digital signatures (verify data integrity)

A digital signature is an electronic signature that can be used to authenticate the identity of the sender of a message or the signer of a document, and to ensure that the original content of the sent message is unchanged. Digital signatures are portable, easily verified and cannot be forged.

It is also acceptable for Hydrographic offices or other Data Server organisations (e.g. RENC/VAR) to use digital signatures to maintain provenance and data integrity between them in the delivery of ENC information.

Each ENC file (both base and update files) will always have a single unique signature file associated with it. No other files in an encrypted ENC exchange set have a digital signature.

NOTE: An exchange set may contain signatures issued by different data servers and therefore each ENCv file must be authenticated individually.

Technical overview of digital signatures

Data authentication is provided using a digital signature compliant with the Digital Signature Standard (DSS). DSS uses the Secure Hash Algorithm (SHA-1) to create a message digest (hash). The message digest is then input to the Digital Signature Algorithm (DSA) to generate the digital signature for the message using an asymmetric encryption algorithm and the private key of a key pair, for later decrytpion with the corresponding public key.

A consequence of encrypting the message digest with the private key is that anyone who has the public key (which as its name suggests can be made public) can decrypt and verify the message digest.

OEM and Data Client Processes

Data Clients

Data Clients are the users of ENC information and will receive protected information from Data Servers. The OEM is responsible for developing software applications capable of authenticating the ENC digital signatures and decrypting the ENC information in compliance with the procedures defined in S-63. Navigators with ECDIS are examples of Data Clients.

OEMs

OEMs subscribing to S-63 must build software routines in support of the scheme. S-63 contains specifications and test data for validating the manufacturer's software application. The SA will provide the OEM with a unique set of manufacturer codes (M_KEY and M_ID). The OEM must also provide a secure mechanism within their software systems for uniquely identifying each end user installation. The Data Servers will use the M_KEY and HW_ID information to issue encrypted ENC cells keys to a Data Client specific installation. Each ENC is encrypted with a unique cell key.

The OEM is required to cooperate in the protection of ENC information within end user systems. For example, if a hardware device such as a dongle is used to store the HW_ID, the Data Client must periodically check for its continued presence. The Data Client must cease to operate if the device is removed after the application is started. On a networked system the security device must control the number of concurrent users of the application; this will depend on the terms and conditions of a Data Server's service.

Annex C - ENC Update Status Report

Annex C of S-63 elaborates the definition of an “up to date” ENC. This is required by MSC.232(82) and all ECDIS users are required to be able to demonstrate to a vetting inspector that their ECDIS and its embedded ENCs are up to date.

This Annex specifies the format and content of an “ENC update status report” which, if implemented, will demonstrate the revision status of ENCs within the ECDIS SENC.

The ENC update status report is designed as a concise and standardised format to assist end users in satisfying themselves that their ENC data is “up to date” and help satisfy inspection requirements in that respect.

The report is designed for two individual use cases:

• To ensure that all ENC cells loaded into the SENC are up to date for the next leg of a particular route
• To ensure that all ENCs loaded into the SENC are up to date.

See also

• ECDIS
• ENC

Resources

• IHO Standards and Specifications
• How PKI works
• Encryption vs. Hashing