Versions Compared

Old Version 18

changes.mady.by.user Jenna Bennett

Saved on

compared with

New Version Current

changes.mady.by.user Chloe Gibson

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Roadmap Item Retired. Effective Date reached.

Page Properties
id1

ID

RM97

Version

4.0.2

Type

Roadmap Item

Frameworks

Page Properties
id2

Title

Identity and Access Management Support for Vendor Agnostic Smartcards

Description

COVID-19 response has presented NHS Digital the opportunity to work with system providers to deprecate support for old middleware and introduce support for vendor agnostic Smartcards including PIV compliant Smartcards.

Date Added

 

Standards and Capabilities

External Interface Specification (EIS)

Change Route

Managed Capacity - Other

Change Type

New

Status

PublishedClosed

Publication Date

Effective Date

Incentives / Funding

Yes

Incentive Dates

Incentive Start Date: The latter of the 10th August 2020 or the date on which this Roadmap Item attains “Published” status.

Incentive End Date: 12th October 2020

Payment Rules

Applicability: Foundation Catalogue Solution Sets that are compliant on the date of publication of this Roadmap Item.

Incentive amount: £100,000 per applicable Foundation Catalogue Solution Set.

Payment Rules (Stage 1 and Stage 2 are defined in the Assurance Approach section)

  • Stage 1 - £50,000 on DevMac receipt where integration is with the original 3rd party software provided by the Catalogue Authority. To have a sliding Scale of 100% on or before 14th September 2020 reducing by 5% each calendar day until 28th September 2020 and remaining at 25% until 5th October 2020 and zero beyond the 5th October 2020. Payment subject to achieving Stage 2 by 12th October 2020.

  • Stage 2 - £40,000 on DevMac receipt where integration is with the revised 3rd party software provided by the Catalogue Authority which corrects 3rd party software issues identified during pilot testing. 100% on or before 31st December 2020 and zero thereafter.

  • Stage 3 - £10,000 on DevMac FRA receipt with a sliding Scale: 100% on or before 17th March 2021 reducing by 5% each calendar day until and including the 31st March 2021 and zero beyond the 31st March 2021.

Note, the above method of calculation overrides that set out in paragraph 3 of Part C-1 of Framework Schedule 4.1 (Charges and Invoicing).

...

NHS Digital are looking for the GP System suppliers to remove the reliance on the proprietary interfaces and DLLs in favour of using the generic (NHS Digital) interface that allows for the support of all Smartcard types. This will also help mitigate the medium term roadmap challenges. NHS Digital understand that this will also resolve issues we’ve seen in the INT environment when performing exploratory assurance of the GP Supplier systems with the new Entrust Virtual Smartcard. Two examples are outlined below:

  1. A User can authenticate to the system. If the session locks, entering the PIN to unlock does not work. A workaround is to temporarily disconnect the connection between the devices smartphone and  (mimicking physical Smartcard removal) re-connect. This causes the session to automatically unlock and does not require the PIN entry again.

  1. A User can authenticate to the second system, however, if the session locks and you are asked to enter a PIN to unlock, it doesn't matter what you do (disconnect /reconnect VSC, Enter PIN, etc.) it doesn't unlock and instead throws an error. There is no workaround to the issue.

These issues are likely to be caused by the application expecting that the target Smartcard is a specific type or one that is compatible when it is not and therefore the commands are failing and causing an error.

...

The two known artefacts that reference the areas of code that NHS Digital believe need to change are outlined below.

 https https://digital.nhs.uk/developer/api-specifications/spine-external-interface-specification

 EIS Part 6 – Spine security Broker (SSB)

...

This means the following need to be taken into consideration:

  1. Support for PIV Cards in the NHS Digital controlled Identity Agent 2.x.x ( and have been for some time) which, means they can be used successfully to perform Authentication via this Identity Agent. The legacy B.T. Identity Agent does not work with such Smartcards. It should be noted that the B.T. Identity Agent has been out of support for a significant period of time and as far as NHS Digital is concerned this has long been deprecated in favour of the NHS Digital 2.x.x Identity Agent which, is under active maintenance and development.

The B.T. Identity Agent will continue to work with the physical cards (Gemalto Cards and the Oberthur Cards, i.e. Series 4,5,6,8 cards) but PIV based Smartcards will not work with this product. Should PIV Cards (virtual or physical) be used in an environment, the NHS Digital Identity Agent will be required to successfully authenticate using such cards. Entrust Virtual Smartcards will not work with B.T. Identity Agent.

  1. Suppliers’ applications that need to perform Advanced Electronic Signatures will not be able to perform it when presented with a PIV based Smartcard if they use BT Identity Agent. This is due to the lack of compatibility between the PIV Card and the legacy integration requirement. This will not change as the PKCS11 requirement is superseded and will be discussed in detail further in the documentation. 

A change to the suppliers’ application code is required so that full support for all legacy, current and future Smartcards can be provided whilst reducing the complexity of the integration for suppliers.

...

The API requires the following method calls to be made:

  1. Create an instance of the signing object SCardDigitalSignature

  2. Create a SHA1 hash of the data that is to be signed.

  3. Invoke the ObtainTheSigningCertificate method on the signing object to retrieve the X.509 Certificate that supports Non-Repudiation for Digital Signatures.

  4. Invoke the SignHashGeneratingPKCS1v1_5Signature method on the signing object passing in the Smartcard Name, Smartcard Pin Number , Signing certificate , the hash digest and hashing algorithm. If successful, the Base64 string representation of the PKCS1 V1.5 digital signature is returned through a call back variable.

The above steps are required to perform a signing operation with any supported Smartcard without the need to change the product code to support a future card unless NHS Digital update the interface. An example implementation can be seen further down in the documentation.

...

Also, the generation of any other digital signature constructs (e.g. XML-DSIG) is also an application responsibility and is outside the scope of this document.

  1. The user will be sat at a workstation having authenticated to the Spine with their smart card in the reader. This is user authentication and should not be confused with the requirement for a user to enter their passcode for the purposes of signing, although the same passcode is used.

  2. The application workflow requires the user to commit to some content i.e. sign an electronic form.

  3. The user is made aware that they are being requested to commit to the presented content and asked to Digitally Sign the form by pressing a ‘Sign’ button.

  4. On pressing the ‘Sign’ button, a passcode dialogue appears and, the user enters their passcode, which is the same passcode used when authenticating.

  5. The application creates an instance of the Digital Signing object and retrieves the X.509 Digital.

  6. The application will then generate a hash of the form to be digitally signed and pass it to the Smartcard via the Digital Signing object whereupon a digital signed copy will be generated on the Smartcard and passed back to the application.

  7. The application will then validate the chain of certificates up to the Spine Root CA. In essence, the application requires a trusted store containing the Spine Root CA certificate and the Sub CA certificate used to issue the Content Commitment Signing certificate. This chain will enable the application to establish that the Sub CA issued the signing certificate

  8. The application will validate the user’s SSO Token, the principle being that a valid token can be accepted as confirmation that the user’s Smartcard and associated certificates and keys are currently valid at that time.

  9. The application will then securely log details about the transaction, which may include information such as date and time, SSO Token validation status and the hash of the transaction.

Signing Process Psuedo Code – replaces 6.10.5

...

NHS Digital are looking to take a simple approach to assurance

  1. Collaborative working at the developer level to understand code changes required

  2. Early proving of capability in INT with end to end systems to confirm issues with authentication and signing work with EPS and pharmacy systems.

  3. GP System suppliers to run a functional and non-functional regression pack that mitigates the risks identified by the GPITF assurance risk assessment and that satisfies GP System supplier’s own assurance requirements given this is a critical function.

NHS Digital are looking to work collaboratively with the system providers to provide some workable code.  NHS Digital have worked at the developer to developer level to explain, guide and support the changes required. This has been well received so far as there are gaps in knowledge of historic code that has remained untouched for a number of years and because we have found that the digital signing operation may not be the only place the Smartcard is being leveraged by the application and, NHS Digital have the capabilities to help guide the developers to make any additional changes that are required.

...

 In order to successfully meet the stage 1 criteria then the suppliers will have:

  1. Demonstrated early proving in INT by successfully authenticating using an Entrust virtual Smartcard and an end to end prescription signing test with EPS.

  2. Run agreed regression test packs that cover authentication and EPS signing with particular focus the following areas outlined in the risk log attached:

  • Regression test of National Service Integration

  • Regression test of prescription signing

  • Regression of two areas of Information Governance concern

  • Regression testing of Smartcards and other

  • Non-functional regression (no degradation of performance)

  • Non-functional regression test of other access methods (eg VDI)

  • Regression around other subsidiary suppliers to be considered

  • RFO regression to be considered  

...