Version 1: Release Note 28 November 2014


Required Trust Anchor Cells and related Device requirements



Download 4.8 Mb.
Page25/258
Date03.04.2021
Size4.8 Mb.
1   ...   21   22   23   24   25   26   27   28   ...   258

Required Trust Anchor Cells and related Device requirements


The Trust Anchor Cells specified in Table 4.3.2.5 by TrustAnchorCellIdentifier are those required on each deviceType. Additionally:

  • a GSME shall have a Trust Anchor Cell capable of storing Key Agreement Security Credentials for a PPMID; and

  • a PPMID shall have a Trust Anchor Cell capable of storing Key Agreement Security Credentials for a GSME.

The types of Device and the corresponding value of deviceType shall be defined in ASN.1 notation by:

DeviceType ::= INTEGER {

gSME (0),

eSME (1),

communicationsHubCommunicationsHubFunction (2),

CommunicationsHubGasProxyFunction (3),

type1HANConnectedAuxiliaryLoadControlSwitch (4),

type1PrepaymentInterfaceDevice (5),

type2 (6)

}

Every Device shall:



  • have storage allocated capable of holding Security Credentials as required by Table 4.3.2.5 for its Device type; and

  • have all the Trust Anchor Cells, specified in Table 4.3.2.5 as being required for its Device type, populated with Security Credentials that comply with the requirements of this GBCS. Critically, root, recovery and accessControlBroker Trust Anchor Cells shall be populated with valid credentials for each of those three Remote Parties.













Type of Device (= is required; empty = is not required)
















ESME

GSME

CH (CHF)

CH (GPF8)

HCALCS

PPMID




deviceType value(s)

1

0

2

3

4

5




TrustAnchorCellIdentifier



















No

remotePartyRole

keyUsage

cellUsage



















1

Root

keyCertSign

Management













2

Recovery

digitalSignature

Management













3

Supplier

digitalSignature

Management















4

Supplier

keyAgreement

Management
















5

Supplier

keyAgreement

prePaymentTopUp

















6

networkOperator

digitalSignature

Management

















7

networkOperator

keyAgreement

Management

















8

accessControlBroker

digitalSignature

Management

















9

accessControlBroker

keyAgreement

Management













10

transitionalCoS

digitalSignature

Management















11

wanProvider

digitalSignature

Management


















Table 4.3.2.5: Requirements for Trust Anchor Cells by Device Type

For clarity, the GPF and CHF shall each have their own set of Trust Anchor Cells.

A specific Trust Anchor Cell shall be identified in this GBCS using the notation {remotePartyRole, keyUsage, cellUsage}. For example {supplier, digitalSignature, management} shall refer to the Trust Anchor Cell that holds the Device’s Supplier Digital Signing Security Credentials, so including the Supplier’s:


  • Entity Identifier;

  • Remote Party Role; and

  • Digital Signing Public Key.

Where a Device supports the processing of Remote Party Messages, that Device:

  • shall support the processing of the Update Security Credentials Command; and

  • shall not allow execution of any Remote Party Command other than an Update Security Credentials Command or a Provide Security Credentials Command, nor issue any Remote Party Alerts, in relation to a Remote Party Role where the Remote Party Role stored in a Trust Anchor Cell is different than that of the Trust Anchor Cell itself.

When verifying a Cryptographic Protection applied to a Command instance it receives, a Device shall use the Remote Party Security Credentials that it holds at the time of Command processing.

Devices shall only be capable of replacing Remote Party Security Credentials on receipt of an Update Security Credentials Command specified in this GBCS.


        1. What is the Public Key in each Trust Anchor Cell to be used for – informative


TrustAnchorCellIdentifier

Usage of the Public Key in the Trust Anchor Cell

remotePartyRole

keyUsage

cellUsage

Root

keyCertSign

management

Used only in Certification Path Validation to check that Certification Authority Certificates and Certificates related to change of root credentials were validly issued

Recovery

digitalSignature

management

Used only to verify recovery’s signature on Update Security Credentials Commands addressed to the Device

Supplier

digitalSignature

management

Used to verify the supplier’s signature on Critical Commands the supplier has addressed to the Device

Supplier

keyAgreement

management

Used in applying MACs to Alerts and Responses addressed to the supplier, where they are not Critical

Used in unencrypting encrypted data in Commands from the supplier and in encrypting data in Alerts and Responses addressed to the supplier



Supplier

keyAgreement

prePaymentTopUp

Used to check the supplier MAC on prepayment top up Commands. The supplier can decide whether this is the same key as the Key Agreement key used for other purposes

networkOperator

digitalSignature

management

Used to check the signature of the networkOperator on Critical Commands the networkOperator has sent to the Device. This only equates to Update Security Credentials Commands

networkOperator

keyAgreement

management

Used in applying MACs to Alerts and Responses addressed to the networkOperator, where they are not Critical

Used in encrypting data in Responses addressed to the networkOperator



accessControlBroker

digitalSignature

management

Used to verify the accessControlBroker’s signature on Commands addressed to the Device

accessControlBroker

keyAgreement

management

Used in checking the accessControlBroker MAC on Commands received and to calculate the MAC for Responses addressed to the accessControlBroker

transitionalCoS

digitalSignature

management

Used only to check transitionalCoS’s signature on Update Security Credentials Commands received by the Device

wanProvider

digitalSignature

management

Used by the Communications Hub (CHF) to verify the wanProvider’s signature on Critical Commands addressed to the Communications Hub

Table 4.3.2.6: Use of Public Keys in each Trust Anchor Cell
        1. Mapping a Command to the Remote Party Security Credentials to be used in verifying the Command’s cryptographic protections


Except for the Security Credentials related Commands (see Section 13), a Device shall apply the requirements of this Section 4.3.2.7 to identify which of the Remote Party Public Keys that it holds are to be used to verify the cryptographic protections on a Command.
          1. Message Authentication Codes

Where a Command is a Prepayment Top Up Command, the supplier MAC in that Command shall be verified using the Public Key in Trust Anchor Cell {remotePartyRole supplier, keyUsage keyAgreement, cellUsage prePaymentTopUp}, along with the Device’s Key Agreement Private Key.

All other MACs in Commands shall be verified using the Public Key in Trust Anchor Cell {remotePartyRole accessControlBroker, keyUsage keyAgreement, cellUsage management}, along with the Device’s Key Agreement Private Key.


          1. Signature

Where a Command has a Digital Signature, the Device shall identify the Remote Party Role(s) which can legitimately sign the Command according to the message code identified in the Mapping Table.

If there is only one Remote Party Role so identified, then the signature shall be verified using the Public Key in Trust Anchor Cell {remotePartyRole (the identified remote party role), keyUsage digitalSignature, cellUsage management}.

If there is more than one Remote Party Role so identified, the Device shall use the Business Originator ID in the Command to identify the Trust Anchor Cell(s) where:


  • keyUsage = digitalSignature;

  • cellUsage = management; and

  • existingSubjectUniqueID = the Business Originator ID in the Command

If there is only one Trust Anchor Cell so identified, then the signature shall be verified using the Public Key in that Trust Anchor Cell.

If there is more than one Trust Anchor Cell so identified the Device shall attempt to verify the Digital Signature using each Trust Anchor Cell identified. These attempts shall be according to the following precedence, and attempts to verify shall cease when a signature verification succeeds:



  1. supplier

  2. wanProvider

  3. networkOperator

  4. accessControlBroker

For clarity, other Remote Party Roles on Devices are limited to Commands related to Security Credentials and so cannot have Trust Anchor Cells identified according to this Section 4.3.2.7.2.

        1. Directory: government -> uploads -> system -> uploads -> attachment data -> file
          file -> Remove this if sending to pagerunnerr Page Title Light Rail Security Recommended Best Practice
          file -> 8 Section 1 : Sport
          file -> Notice of exercise of additional powers of seizure under Sections 50 or 51 of the Criminal Justice and Police Act 2001
          file -> Home office circular 004/2014 Powers to search for and seize invalid travel documents in Schedule 8 to the Anti-social Behaviour, Crime and Policing Act 2014
          file -> Consultation on the Royal Parks and Other Open Spaces (Amendment) (No. 2) Regulations 2012
          file -> Crown copyright 2012
          file -> This is the Report to Government by the Film Policy Review Panel The brief
          file -> Impact Assessment (IA)
          file -> Dcms/Wolfson Museums and Galleries Improvement Fund a public-Private Partnership (2002-2010)


          Share with your friends:
1   ...   21   22   23   24   25   26   27   28   ...   258




The database is protected by copyright ©essaydocs.org 2020
send message

    Main page