Hacker News new | past | comments | ask | show | jobs | submit login
Launch HN: MedCrypt (YC W19) Medical Device Cybersecurity
30 points by mikekij 4 months ago | hide | past | web | favorite | 14 comments
Hi HN! We're Eric and Mike, founders of MedCrypt (https://www.medcrypt.com). Our mission is to make it easy for healthcare technology companies to build cybersecurity features into their products.

I (Mike) was previously a product manager at a medical device company and witnessed an increasing concern about the security posture of Internet-enabled medical devices. This culminated in a couple of big device companies needing to issue recalls for their medical devices due to cybersecurity vulnerabilities. It struck me as an interesting transition from cybersecurity being a compliance requirement and instead a concern when managing patient safety.

Being concerned about the lack of resources available to implement data security properly, or at all in some cases, we decided to build a platform that helps healthcare software and medical device companies properly integrate data security features into their products, while actively monitoring them for vulnerabilities and suspicious behavior.

We address this problem by providing our customers with a configuration driven library that exposes a simple API to access data security operations, crypto library versioning/vulnerability tracking, key management, and device behavior monitoring. The features our solution provides also happen to cover all of the FDA’s new requirements for data security in medical devices (https://www.fda.gov/downloads/MedicalDevices/DeviceRegulatio...). These requirements place special emphasis on proper data encryption, signature verification, intrusion detection, and vulnerability monitoring.

While medical device vendors could go through the trouble of pulling together open source crypto libraries, certificate authority APIs, and monitoring solutions, or even write some of their own from scratch, we believe MedCrypt's platform offers a better alternative. We handle the complexity of integrating open source crypto libraries with PKI and monitoring infrastructure and provide simple API calls for key provisioning, certificate generation, data security ops, and monitoring.

Medical device vendors use their account on the MedCrypt platform to tell us about the individual computing components that make up their device, what types of data are stored or transmitted over the wire, and what kind of security is required. This allows us to point the vendor to the appropriate MedCrypt library (C/C++ libraries or bindings for NodeJS, Java, C# .NET, etc.) to use for each component and creates a generic provisioning configuration that the MedCrypt library uses to generate the appropriate key pairs, communicate with PKI, and register CBOM metadata for vulnerability tracking purposes.

Once the device and its keys are approved (via our provisioning API or predefined filters) and the certificates and signed configuration are delivered to the device, MedCrypt's library uses the certificates and the security configuration to enable simple API calls to secure the device's data.

For example, after being provisioned, if a glucose monitor is required to sign each set of measurement data sent to a central system called "data-capture", the API call is boiled down to:

  int returnCode = glucoseMonitor.dataFor(&securedData, "data-capture", rawMeasurementData);
Under the hood the MedCrypt library is using the signed data security configuration to select the cryptography resource, sign the data with the appropriate secret key, construct a data payload that encapsulates the original data and signature for delivery to the "data-capture" server, and (if enabled) registers monitoring events with regard to when and with which keys a signing operation occurred.

On the other end, the "data-capture" server can verify and get access to the measurement data through an API call:

  int returnCode = dataCapture.dataFrom(&rawMeasurementData, "glucose-mon", secureData);
Again, underneath, the library is using the configuration to establish what type of security is required for this data and whether it can trust the public key referenced by the signature on the measurement data. If the public key is trusted and the signature is verified then the original measurement data is returned to the user. The signature data can also be returned so that the integrity and provenance of the measurement data can be verified in the future. If enabled, an event is recorded indicating the status of the signature verification and from which device/keys it was generated with.

The library can also be used to apply security to sockets, encrypt data at the application level, and monitor additional events, all driven by the signed configuration describing the security preferences for this device.

When our monitoring service receives metadata about the security events on the device, we can then scan for anomalous behavior. Our behavior-monitoring baselines are developed using the data from multiple classes of medical devices from multiple vendors, giving our customers access to a dataset larger than they’d be able to build on their own.

Medical device vendors should be able to focus on building innovative clinical features while using best of breed tools and platforms for things like security. We believe we’re building security tools in a way that optimizes data security without compromising clinical functionality.

We’d be excited to hear your feedback, and how you think a healthcare-specific cybersecurity company can help medical device vendors facilitate secure connectivity.

Please check us out at https://www.medcrypt.com




This sounds great. In my previous life in embedded development (not medical) I have had to implement various security protocols and it was always a nightmare. I'm not a security expert and even today I think back to code I wrote and wonder if they're still in service.

Having something like this where I can focus on the function of the device and offload the difficulties of secure communication would have been a godsend.


I think you should come do sales for us!

The dynamic you describe plays itself out in almost every industry. Most biomedical engineers didn’t get into their field to implement cryptography. We’re hoping that a dedicated toolkit for securing medical devices will help their designers get back to work building life-saving technologies!


Does this support modern health informatics interoperability standards currently?

I'm particularly interested if there is good interface with this platform and FHIR/HL7.


Great question! We’re currently focused on intradevice security, or securing the data within a particular device. That seems to be the FDA’s focus currently. We hope to help medical device vendors interface with HL7 / FHIR systems securely in the future.


This certainly looks interesting and I think there is a need for this. I haven't looked too closely but do you have architecture diagrams of how complete solutions built on your system could look?


I was literally working on this last week! Email me at eric@medcrypt.co and I’ll send you a draft to get your feedback.

We definitely need some simple, high-level figures show how the libraries interact with the PKI nodes as well as local libraries and crypto elements on the device.

Users can also interact with a web API to control provisioning processes and retrieve telemetry data and we'll depict that as well.


I will send you a mail. I definitely recommend to provide more clarity on the website. I have been in medical devices now for a few years and it's really big deal and effort to add components like yours so it's good to alleviate concerns as soon as possible.


This is a great point. Thank you for pressing us on this and being willing to give us some feedback. We'll get some meaningful architecture diagrams in the docs asap.


Can you talk in more detail about the cryptography you're using?


Absolutely, we wrote our own post-quantum crypto engine that has no side-channel attacks and has little to no performance overhead... Just kidding!

We do not write any of our own crypto. We use common open source libraries like libsodium, WolfSSL, OpenSSL, etc. under the hood. We provide binary versions of our library linked against the appropriate libraries for the customer, or customers can build their own combination of our library+crypto dependencies from source.

Sometimes we help customers get the compile options right to take advantage of, say, NEON instructions to optimize for an ARM target, but that's about the extent in terms of touching the actual crypto library.


That's good to hear. Presumably you're doing encryption at rest in addition to TLS. Can you talk about the constructions you've come up with to do that?


Admittedly, most of our focus (on the crypto end) has been on simplifying the key provisioning/management process, establishing secure sockets, and signing and verifying data. Our protocol does allow for storing a source ID and additional data with encrypted message data as a single serialized set of binary data to be written to disk or database. When this data is deserialized we can use the source ID to locate the key and then recover the original data with the AD and encrypted data.

Underneath, calls would be made to the open source crypto lib yielding, for example, data encrypted via ChaCha20 stream cipher with Poly1305 MAC authentication.

Also, our platform generates a provisioning configuration that tells the device to generate a dedicated set of keys for the purpose of encrypting data at rest. Those keys would not be used for any other signing or socket security operations. In general, if the target hardware can support it, we create dedicated keys for each type of data security operation (read multiple RPCs sending different types of data like log data, command-control data, images). We think this is especially important for encrypting data with LTKs since there have been cases where encrypting with a secret key has resulted in secret key leakage.


What does it mean to say that something has no side channel attacks? Do you mean no known side channel attacks? If so, doesn't any product with regular security updates meet this criteria? Or have you somehow ruled out the possibility of side channel attacks (which sounds impossible to me, but I am not an expert)


Sorry, I made a bad joke above.

I'm guessing there are almost certainly side-channel attacks (discovered or not) in most crypto libraries. How easily they're exploited is another topic.

We don't believe we need to build more cryptography engines. We just think we need to make the existing crypto libraries easier to use in conjunction with PKI, vulnerability monitoring, ease of patching, and especially in the context of documentation and testing in the eyes of the FDA.




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: