Trusted connection

Clarifications:

• Health IT needs to provide a level of trusted connection using either 1) encrypted and integrity message protection or 2) a trusted connection for transport. Either of these methods must be demonstrated in accordance with the following standards: Annex A: FIPS Publication 140-2, Security Requirements for Cryptographic Modules and FIPS PUB 180-4, Secure Hash Standard, 180-4.
• A “trusted connection” means the link is encrypted/integrity protected according to § 170.210(a)(2) or (c)(2). As such, ONC does not believe it is necessary to specifically name HTTPS and/or SSL/TLS as this standard already covers encryption and integrity protection for data in motion. [see also 80 FR 62676]

Technical outcome – The health IT offers a user encrypted and integrity message protection.

Clarifications

• No additional clarifications.

Technical outcome – The health IT provides the user a trusted connection for transport.

Clarifications

• The tester is required to view the encryption handshake to ensure that the digital certificates, where used, are being invoked during the connection. Developers have freedom to demonstrate the encryption handshake based on the technology they are using. For example, if a developer has a browser-based module that uses HTTPS, the developer could demonstrate the "lock" icon in the browser that indicates that HTTPS is present and working properly.
• The verification step is verifying that the transport is conducted using a trusted connection configured to conform to the required level of encryption and hashing standard. The communication content is not examined, only the configuration and the handshake, and where used, the digital certificates. The messages are not examined as with alternative 1. The lab does not need to verify the messages, only the trusted connection.