4

I have written an c# 4.0 application that analyses the microphone input and records DTMF tones that represent credit card numbers entered by our clients. This all works well, but since we are working under PCI Compliance (see www.pcisecuritystandards.org), we don't want to allow the logged in user (call centre staff) to listen or even record the microphone input so that they then can parse the credit card numbers on their own with a 3rd party app or their phones. So the question I have is:

  • How can I restrict the microphone input to a specific application so that it can't be heard or recorded somewhere else?

If there is no solution to this, the 2nd question arises:

  • How can I restrict the microphone input to a specific user so that it can't be heard or recorded somewhere else (I could run the software as a Windows service under specific user credentials)?

Kind regards, JB

Chief Wiggum
  • 2,784
  • 2
  • 31
  • 44
  • If its possible at all it would be a security policy thing and for that I'd suggest you'd be better off on serverfault ... – Goz May 08 '13 at 06:14
  • A trained user can decode DTMF by just listening to the tones. You have a much bigger problem, you'll need to cut off the signal entirely. That requires interfacing with the PBX equipment. Standardization is poor, work with the PBX vendors to get somewhere. – Hans Passant May 12 '13 at 22:17

5 Answers5

1

You should be able to do it with the Core Audio API. For each playback device and capture device in the system, you can control whether the device can be used in exclusive mode.

One drawback - there is no support for Core Audio API under Windows XP.

user1764961
  • 673
  • 7
  • 21
  • Cheers for the idea. Unfortunately I have to be able to use it on Windows XP (even if the support runs out in less than a year). But thank you for your suggestion! – Chief Wiggum May 19 '13 at 11:28
1

I think the solution to your problem is to write a KS Filter

Create a Kernel Streaming filter that is able to decode the DTMF on demand of your application and send the decoded data to your application. When the filter is in DTMF decoding mode, it just outputs silence to the rest of the filter stack.

If an USB audio device is used, you could also write a GFX Filter instead, which can be configured on a per-user-base. But this only seems to work for 32-bit operating systems. WinDDK has a sample called gfxswap.xp.

huysentruitw
  • 27,376
  • 9
  • 90
  • 133
  • Thank you again for your idea. We will investigate it further in case Olegs suggestions will not work out as planned. – Chief Wiggum May 19 '13 at 11:29
1

The main way to restrict access to device is setting of Security Descriptor on the device. So granting of the permission for specific user group is the way in which you should go.

The exact implementation for Windows XP could be different from later versions of Windows. Windows 8 have new possibilities too. Audio Mixer APIs can be used in Windows XP. Starting with Vista Windows Multimedia Device (MMDevice) API can be used. MMDevice API's implementation of the property store. You can use IPropertyStore::SetValue and IPropertyStore::Commit to change properties. Unified Device Property Model are introduced starting with Windows Vista. There are different Windows API which uses internally SetupAPI to access to devices and to set it's properties (see here). I think that you should set PKEY_Device_SecuritySDS property to secure device. One can use old APIs like SetupDiSetDeviceRegistryProperty and SetupDiSetClassRegistryProperty to set the properties on Windows XP (see here).

If I start on my computer devmgmt.msc and examine default property of microphone device then I can see Security Descriptor

enter image description here

What you need is to change it so that only specific user groups (or users) access it.

There are PKEY_Device_SecuritySDS and PKEY_Device_Security properties which can be change by SetupDiSetDeviceProperty and SPDRP_SECURITY_SDS or SPDRP_SECURITY (see here). Usage of SDS parameters (PKEY_Device_SecuritySDS or SPDRP_SECURITY_SDS) could be easier because there use readable Security Descriptor Definition Language (SDDL).

After you change security descriptor on the device you need use SetupDiSetClassInstallParams and SetupDiCallClassInstaller with DIF_PROPERTYCHANGE and DICS_PROPCHANGE to reset the device. You can find the code example in the source code of devcon utility on WinDDK. Alternatively you can use CM_Disable_DevNode and CM_Enable_DevNode to restart it with new properties.

Oleg
  • 220,925
  • 34
  • 403
  • 798
  • Sounds great, I'll look into it on Monday (it's already lunch time in NZ...). – Chief Wiggum May 18 '13 at 01:15
  • @JamesBlond: I'm wondering if you got it working with this method? – huysentruitw May 22 '13 at 19:25
  • @WouterHuysentruit: I described here shortly what I used in application which I developed for one my customer to secure [Windows Portable Devices (WPD)](http://msdn.microsoft.com/en-us/library/windows/hardware/ff597729.aspx) and removable medias. To enumerate devices I used code close to the code from [the answer](http://stackoverflow.com/a/3439805/315935) and [the answer](http://stackoverflow.com/a/3100268/315935). You understand that I can't post the code developed for the customers, but the same ideas should work for audio devices too I hope. – Oleg May 22 '13 at 19:36
  • @JamesBlond: thanks for the update. I might have to do the same in a future project, that's why I was asking. – huysentruitw May 22 '13 at 19:38
  • @WouterHuysentruit Unfortunatly I did not find the time yet to test it out. I was a bit sidetracked with other projects and this has to wait for a few weeks :-( – Chief Wiggum May 22 '13 at 21:40
1

You can use ASIO audio drivers in your application.

ASIO is a technology developed by Steinberg to provide low latency audio input and output, and as a side effect, requiring a device using an ASIO driver completely restricts the device use to the process that required it, in addition to multiple other advantages that may be irrelevant to your needs.

It is available for every soundcard thanks to the ASIO4ALL project, so compatibility won't be an issue as long as you provide it with your application

For more informations, check out the wikipedia article about ASIO here, or pick up the SDK here ( you will need to register a Steinberg Developer account to proceed )

SudoGuru
  • 385
  • 1
  • 10
  • Sounds very interesting so far. I've looked into it and will investigate it further in case I won't be able to lock it down with the suggestions from Oleg. Cheers! – Chief Wiggum May 19 '13 at 11:26
1

Will it be helpful if you can control (MUTE) the VOLUME of the sound device and set it back to it's former state once you are done? You can look at this link for ideas. Good luck.

Justjyde
  • 322
  • 1
  • 3
  • 13
  • Not really as far as I understand your suggestion. I will have to grab the input from the audio device and even if I mute the output a user might still be able to use a recorder software on the machine (even if it's locked down). But thanks for the link. – Chief Wiggum May 19 '13 at 03:10