All,
First and foremost I appreciate everyone’s participation during the monthly TC meeting this month and for the great comments and feedback on the subject of WS-BD security. I especially appreciate Kevin and Ross’s willingness to handle
the procedural aspects of the committee so I can spend more time being an engineer. Over the last couple of days I have spent some time reflecting on the various use cases and scenarios that hopefully WS-BD is used and some ideas about how security fits into
those scenarios. I know this will be a challenging issue, but I am sure as a group we can find an elegant solution.
Let me start by saying I strongly believe that provisioning\configuring the device\service should
NOT be part of the specification. I think that is completely reasonable to allow each vendor to have their own configuration and provisioning system. This configuration and provisioning should also cover the exchanging of any keys or certificates.
My two objectives when looking at security around WS-BD is to ensure data privacy and to provide authenticity. I don’t want to solve all of the problems at the WS-BD layer, but I would like to be able to solve as many as we can while still
providing a means for different levels of security to be implemented without creating a standard that in practice does not conform to a standard.
I appreciate and agree with the fundamental concept that the WS-BD protocol be a replacement for traditional proprietary interconnects such as those over USB. The problem is first, USB has a certain level of security built in due to its
physical connection to the computer. Devices operating over WS-BD may or may not be able to benefit from the physical security associated with a wired connection. In the existing appendix dealing with security there is an assumption that the user of the
device will have control over the network that the device is functioning on. This is probably a safe assumption when the device is being used with in a corporate network or other private network, but if WS-BD device are destined to consumer or even mobile
enterprise employees there are likely to be situations where the device would need to be connected to a network that is outside the control of the user.
For these reasons I propose that TLS be a functional part of the specification. What I propose is that an information method always be available over HTTP. This could be existing INFO method with a modified response or a new SecurityInfo
method that allows the consumer to discover what security is required to connect to the device. I also propose that a new error code be added to the existing “securable” methods that informs the caller of a secure method over an unsecured transport is not
allowed. There are obviously a number of details that would need to be worked out, but from a very high level this is what I would like to propose to the committee as the minimum measure that we include as part of the standard. This would not preclude a
device from functioning completely over an unsecured HTTP connection, but it would provide a set of standards for device to function over HTTPS.
Adding details for how to implement TLS to the specification provides both a level of privacy and authenticity between the client computer and the device. This does not however provide any privacy to who may actually be consuming the samples
that are being captured. To help provide privacy and authenticity to third party consumers of biometric samples I have two non-exclusive proposals, one to address authenticity and the other to provide privacy.
To help provide authenticity I propose that the standard provide for an optional signature element to be part of the sample data returned from the device. The signature would be on both the metadata and the actual image. This would provide
the authenticity that could greatly assist in securing remote authentication.
To provide privacy, encrypting the data would be recommended. Since theoretically multiple applications could share the same device it would be best if each application using a WS-BD could have their own unique keys. As stated at the
beginning of the email, exchanging keys would need to be handled outside of the specification. Once the keys had been exchanged, when an application when an application wanted to acquire an encrypted sample it would note so in the request as well as specifying
the identifier of the key the device should use to do the encryption. This identifier would not be secret and would allow multiple applications to share the device without having to share sensitive keys.
I know I am throwing a lot out there, especially on a Friday, but I am very interested in feedback. If anyone has any questions or would like clarification on any part of the above, please do not hesitate to reach out to me.
Thanks for the time and I hope everyone has a great weekend.
Matt Osborne | VP of Engineering | Fulcrum Biometrics
1218 Arion Parkway, Suite 106 | San Antonio, TX 78216 | Ph 210.257.5615
