Why I Changed Jobs
I joined Draeger Medical after finding that KMC Systems was moving towards fewer, larger programs and that I wasn’t likely to get a technical lead role in the next year or more. I started looking and Draeger offered me the chance to have the broader scope I was looking for.
Initial Password Hashing Work
Around the time I joined Draeger to work on their existing ICU monitoring products they received an FDA warning letter (something that is part of the public record). This resulted in the team focus shifting to addressing the concerns in the letter and thus I spent my first couple of months doing some research and prototyping work related to security concerns.
Two of the main issues the FDA was concerned about were security of the network protocols and appropriate password storage. I put together a set of code samples and white-papers to model best practices for saving passwords as salted hashes using PBKDF2 (a more modern replacement for the bcrypt algorithm that was used on older unix systems) with an appropriately selected work function on the various target systems. This code was built in C++ and C# (using a WPF UI for ease of use) with windows and Linux support in the samples I provided.
The samples and white papers were handed over to the development teams as a reference for the device specific implementations.
Network Encryption Work Starts
Around two months with the company, the software architect who had been starting work on providing encryption for the network gave his notice. I had enough experience with cryptography, networking and security issues to know where to start and map out the course to completion so I took over the work. What was handed to me at this point was a very early sketch of how the problem might be addressed with many areas including key/certificate management remaining to be pinned down.
To be honest, at the time I didn’t fully understand the scope of the task in front of me. In particular key management is a far bigger piece of design work than I had realized. The target systems also included older devices with very limited capabilities and very old operating system software that forced some decisions on cipher suites and design approaches. To be clear, nothing in there compromised security but the end result was very specific to the limitations of the target devices and not where I’d go with a new product implementation.
As time permits I expect to write up a description of a completely different design that would be a good fit for a more modern system that needed to send data through a multicast network. This is entirely an issue of the multicast transmission as any modern TLS 1.3 cipher suite should work for point to point connections.
High Level Description of the Starting Point
The details are proprietary so I’ll stick to a high level description here.
The network used TCP connections for some purposes and pushed most data over UDP multicast with a beacon message to inform peers of the presence and capability of devices on the network. Service connections were made over a file transfer protocol that was also unencrypted. This isn’t particularly unusual and suited the needs of the devices well.
When I started on the main network security work the field service transfer process had been ported over to an off the shelf secure file transfer protocol. The other protocols were still using open TCP and UDP and there was no key management as there were no keys.
The architect who had been tasked with coming up with a solution had done a little to sketch out the approach. Use of X.509 certs with ec25519 key pairs was called out. Pre-shared passwords were called for with multicast with no automated key deployment or rotation capability. AES256CBC was called for but using a fixed IV for all packets from a given device.
Some of this was clearly unacceptable and changes needed to be made to get to a shippable design.
First Pass and Prototyping
Given the mix of devices and age of the cryptographic libraries we were limited to TLS 1.2 for point to point. The initial release was intended to only cover point to point connections with multicast encryption following later.
Device CPU performance limitations demanded risk reduction by prototyping the TLS 1.2 ec25519 connections with real devices.
Storage for the X.509 certs was also a potential issue. Some of the devices had limited storage and did not have the ability to store certs in a flash file system. Prototyping of flash writes to blank sectors were sufficient to meet the need and were implemented.
Prototype testing showed that some devices were in fact too limited to negotiate public key TLS connections, even using elliptic curve algorithms, with acceptable performance. This determination forced me to look at other options.
Final Connection Oriented Option
More to come…
Multicast Operation
More to come…
Unit Test
Final Disposition
Static Analysis work with Coverity
< Before | After >