none
Windows Biometric Framework handling of device surprise removal RRS feed

  • Question

  • Hi,

    I'm investigating a case where our biometric device is removed and then reappears (this is normal behavior and unrelated to this issue) and sometimes it appears that the biometric unit isn't getting created after the device reappears.  My question is if the WBF framework handles this case, that is, does it detect that a biometric device has been removed and then subsequently when it reappears, create a biometric unit again.  Would having a biometric session open and locked prevent detection of the remove/attach detection by the WBF framework?  I can provide more details if necessary.

    Thanks,

    Doug Allen

    Tuesday, July 30, 2013 9:28 PM

Answers

  • Hi Doug,

    Yes, WBF processes hardware arrival and removal events for bio sensors. We also pass these events through to the various plug-in adapters, and make them available to client applications in the form of framework change events.

    I suspect the call to WinBioLockUnit is what's causing problems for you. When a bio sensor is removed and reattached, the old biometric unit is torn down and a new one is created. This new bio unit has a new unit ID# associated with it. Because WinBioLockUnit attaches locks a specific UNIT, the lock becomes invalid when the unit is removed. In other words, your application is calling WinBioLockUnit(handle, 1), then when the sensor is reattached, its unit ID has changed to something other than 1.

    (Some background: Many fingerprint readers don't have a unique serial number burned into them. So when a sensor is plugged in, we have no way to tell that it's really the same sensor that was just unplugged. To avoid various kinds of spoofing attacks, we assume that a newly-arrived sensor is unknown to us, and assign it a new unit ID#.)

    Also, if you have any pending operations targeting the unit when it's unplugged (e.g., identify, control unit) those will fail with some device error.

    You might want to try adding framework change-monitoring to the application (see WinBioAsyncOpenFramework) -- probably coupled with some restart logic that detects the new unit ID and releases/reopens the lock. In this case, it would be best if all the work was done using the async mechanisms (see WinBioAsyncOpenSession); it will make the synchronization a bit easier.

    One other caveat: There can be a delay between the sensor being unplugged and the event reaching your framework monitor. This isn't a bio-specific issue. It just seems to take a while for removal/arrival events to bubble their way up the I/O stack.

    Regards,
    -Art Baker
    Senior Software Engineer - Windows Security

    Wednesday, July 31, 2013 2:52 PM

All replies

  • Hi Doug,

    Yes, WBF processes hardware arrival and removal events for bio sensors. We also pass these events through to the various plug-in adapters, and make them available to client applications in the form of framework change events.

    I suspect the call to WinBioLockUnit is what's causing problems for you. When a bio sensor is removed and reattached, the old biometric unit is torn down and a new one is created. This new bio unit has a new unit ID# associated with it. Because WinBioLockUnit attaches locks a specific UNIT, the lock becomes invalid when the unit is removed. In other words, your application is calling WinBioLockUnit(handle, 1), then when the sensor is reattached, its unit ID has changed to something other than 1.

    (Some background: Many fingerprint readers don't have a unique serial number burned into them. So when a sensor is plugged in, we have no way to tell that it's really the same sensor that was just unplugged. To avoid various kinds of spoofing attacks, we assume that a newly-arrived sensor is unknown to us, and assign it a new unit ID#.)

    Also, if you have any pending operations targeting the unit when it's unplugged (e.g., identify, control unit) those will fail with some device error.

    You might want to try adding framework change-monitoring to the application (see WinBioAsyncOpenFramework) -- probably coupled with some restart logic that detects the new unit ID and releases/reopens the lock. In this case, it would be best if all the work was done using the async mechanisms (see WinBioAsyncOpenSession); it will make the synchronization a bit easier.

    One other caveat: There can be a delay between the sensor being unplugged and the event reaching your framework monitor. This isn't a bio-specific issue. It just seems to take a while for removal/arrival events to bubble their way up the I/O stack.

    Regards,
    -Art Baker
    Senior Software Engineer - Windows Security

    Wednesday, July 31, 2013 2:52 PM
  • Hi Art,

    Thanks for the information and for confirming that the framework does handle these remove/attach events.  I'd like to ask a follow-up question if I may.  For the failure case I'm investigating, if I look at our biometric device trace, I can see a series of 3 attach/remove events based on the events CBiometricDriver::OnDeviceAdd and CBiometricDriver::OnReleaseHardware.  Following the first attach, there are subsequent calls to CBiometricDriver::OnGetAttributes and I see a biometric unit creation in the biometric event log.  There are 2 subsequent remove/attach event in out biometric device trace however which aren't followed by a call to CBiometricDriver::OnGetAttributes and there are no further events in the biometric event log.  Could the actions you describe at the application level be responsible for this behavior or is there something else I need to investigate at our driver/adapter level?

    Thanks,

    Doug Allen 


    Doug Allen

    Wednesday, July 31, 2013 4:59 PM