block microphone and speakers due to security reason

Hello,

As part of developing a DLP system, the microphone and speakers should be blocked. My solution involves muting devices by changing the property kAudioDevicePropertyMute. However, this solution allows the user to unmute the device, and the app must implement a property listener to mute the device again. The problem is that muting takes some time and the device is temporarily unmuted. Admittedly, it takes less than a second, but nevertheless, it appears insecure.

Is there an Apple-recommended approach to implement such blocking more securely? Maybe some solution which is based on IOKit.

Thank you in advance, Pavel

Answered by DTS Engineer in 851637022

Is there an Apple-recommended approach to implement such blocking more securely?

No, not really. I'm not expert enough in the audio details of the audio system to make any specific recommendation there, but all of the different options within the audio system would really only change the small details of behavior (for example, performance), not provide some fundamental improvement.

However, I can say that IOKit:

Maybe some solution which is based on IOKit.

...will definitely NOT work, nor would I expect any approach "outside" of the audio system to really work. Here is what I'd be concerned about:

  1. Bluetooth doesn't really "live" in the kernel in the same way other I/O paths do. I haven't looked closely, but I'm not sure it's possible to block Bluetooth audio devices using IOKit.

  2. The range of hardware here is so large that I think it would be VERY difficult to build an IOKit-based solution that I'd be confident could block "everything".

  3. Further complicating #2, I believe at least some "audio hardware" doesn't actually "present" itself to the system as "audio hardware". The hardware itself is configured as vendor-specific and the driver then uses the audio system to construct a "virtual" device that IS in fact backed by a physical device.

  4. There are purely virtual devices, most notably "Airplay" which simply don't "exist" outside of the audio system.

Basically, trying to do this outside the audio system is going to require figuring out lots of edge cases, a huge amount of testing, and is VERY likely to miss "something". More to the point, even if you managed to PERFECTLY* block all audio hardware... you still need to use the audio system to block everything that's purely virtual.

*To be clear, I'm not convinced this is possible but I'll pretend to be an optimist.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Accepted Answer

Is there an Apple-recommended approach to implement such blocking more securely?

No, not really. I'm not expert enough in the audio details of the audio system to make any specific recommendation there, but all of the different options within the audio system would really only change the small details of behavior (for example, performance), not provide some fundamental improvement.

However, I can say that IOKit:

Maybe some solution which is based on IOKit.

...will definitely NOT work, nor would I expect any approach "outside" of the audio system to really work. Here is what I'd be concerned about:

  1. Bluetooth doesn't really "live" in the kernel in the same way other I/O paths do. I haven't looked closely, but I'm not sure it's possible to block Bluetooth audio devices using IOKit.

  2. The range of hardware here is so large that I think it would be VERY difficult to build an IOKit-based solution that I'd be confident could block "everything".

  3. Further complicating #2, I believe at least some "audio hardware" doesn't actually "present" itself to the system as "audio hardware". The hardware itself is configured as vendor-specific and the driver then uses the audio system to construct a "virtual" device that IS in fact backed by a physical device.

  4. There are purely virtual devices, most notably "Airplay" which simply don't "exist" outside of the audio system.

Basically, trying to do this outside the audio system is going to require figuring out lots of edge cases, a huge amount of testing, and is VERY likely to miss "something". More to the point, even if you managed to PERFECTLY* block all audio hardware... you still need to use the audio system to block everything that's purely virtual.

*To be clear, I'm not convinced this is possible but I'll pretend to be an optimist.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thank you for the clarification.

It seems that the solution based on IOKit may be too complex and unstable. So, I believe, the best approach is to use Core Audio (HAL).

Thank you very much!

block microphone and speakers due to security reason
 
 
Q