en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

HIPAA-Compliant IoT Solutions

HIPAA and the IoT

The Internet of Things (IoT) is growing exponentially, with some reports predicting it reaching over 38 billion devices in 2020. With more and more stories emerging of hacked devices coming out, the need to secure the Internet of Things is becoming more urgent, more so for medical device manufacturers with HIPAA in mind.

The U.S. Health Insurance Portability and Accountability Act, or HIPAA, is no joke. HIPAA protects the security and privacy of patients’ Electronic Protected Health Information (PHI or ePHI), and is enforced by the Office for Civil Rights (OCR) of the U.S. Department of Health and Human Services (DHS). If you’re looking for digital certificates for HIPAA-compliant communication, check out our article here.

HIPAA requires that health care providers protect PHI while in transit or at rest, and failure to do so can result in hefty fines. Fines for HIPAA violations can range from $100 to $50,000 per violation, with a maximum penalty of $1.5 million per year. In 2019, 418 breaches led to the compromise of 34.9 million Americans’ PHI. 

Taking steps now to secure patient information and stay HIPAA compliant is certainly the right move. In 2019, network server breaches accounted for 30.6 million individuals’ information being compromised. In 2018, the American Medical Collection Agency (AMCA)’s network server was hacked, leading to 22 million patients having their data compromised. The financial repercussions and loss of business led to AMCA filing for Chapter 11 Bankruptcy. 

[su_divider]

 

HIPAA Information Transmission Requirements

HIPAA states the following regarding information transmission security:

164.312 (e)(1): Standard: Transmission security. Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.

Because HIPAA was meant to be future-proof, it leaves this directive open-ended. Basically, to protect against potentially costly violations, there need to be protocols in place to protect the information transmitted over an electronic communications network.

For an organization, this means that any devices that transmit data over a network, particularly those doing so outside of a company firewall, need to implement a mechanism for authentication and encryption. SSL/TLS can take care of this through either one-way or mutual authentication

[su_note class=”info”]

SSL.com provides a wide variety of SSL/TLS server certificates for HTTPS websites, including:

[su_button url=”https://www.stg.ssl.com/certificates/” target=”blank”]COMPARE SSL/TLS CERTIFICATES[/su_button]

[/su_note]

SSL/TLS for HIPAA-Compliant IoT

The SSL/TLS protocol uses asymmetric encryption to secure data shared between two computers on the Internet. In addition, SSL/TLS ensures that the identities of the server and/or client are validated. In the most common scenario, using one-way authentication, an HTTPS server provides a visitor’s browser with a certificate which has been digitally signed by a publicly trusted Certificate Authority (CA) like SSL.com. 

The mathematics behind SSL/TLS ensure that a CA’s digitally signed certificates are practically impossible to falsify given a large enough key size. Public CAs verify the identity of applicants before issuing certificates. They are also subject to rigorous audits by operating system and web browser providers to be accepted and maintained in trust stores (lists of trusted root certificates installed with browser and OS software).

[su_divider]

SSL and Authenticating Clients

For most applications, SSL/TLS uses one-way authentication of a server to a client; an anonymous client (the web browser) negotiates an encrypted session with a web server, which presents a publicly trusted SSL/TLS certificate to identify itself during the SSL/TLS handshake. 

While one-way authentication is perfectly acceptable for most web browsing, it is still vulnerable to credential theft attacks such as phishing in which attackers target login credentials such as usernames and passwords. Phishing attacks account for 22% of data breaches, according to a report by Verizon. For additional protection, you can opt for mutual authentication. In mutual authentication, once the server is authenticated during the handshake, it will send a CertificateRequest message to the client. The client will respond by sending a certificate to the server for authentication. With both sides authenticated with PKI, mutual authentication is that much more secure than traditional password-centric methods.

[su_divider]

Mutual Authentication and IoT

For medical device manufacturers, mutual authentication of servers and devices might be the best option, as to leave nothing to chance with the identities of client and server. For example, once a smart medical device is connected to the internet, a manufacturer might like it to send and receive data to and from the company’s servers, so that users can access information. To facilitate this safe transfer of information, the manufacturer could consider the following:

  • Ship each device with a unique cryptographic key pair and client certificate. Because all communication will be between the device and the company’s servers, these certificates may be privately trusted, offering additional flexibility for policies like certificate lifespan.
  • Provide a unique device code (such as a serial number or QR code) that the user can scan or enter into their user account on the manufacturer’s web portal or smartphone app to associate the device with their account.
  • Once the device is connected to the internet via the user’s Wi-Fi network, it will open a mutual TLS connection with the manufacturer’s server. The server will authenticate itself to the device and request the device’s client certificate, which is associated with the unique code entered by the user into their account.

The two parties to the connection are now mutually authenticated and can send messages back and forth with SSL/TLS encryption over application-layer protocols like HTTPS and MQTT. The user can access data from the device or make changes to its settings with their web portal account or smartphone app. There is never any need for unauthenticated or clear-text messages between the two devices.

[su_divider]

Last Word

Don’t get caught out in the open. If you’re interested in SSL.com’s custom IoT solutions, fill out the form below to get more information.

Subscribe to SSL.com’s Newsletter

Don’t miss new articles and updates from SSL.com