Using secure context properties

The best way to ensure that sensitive data is protected is to set a secure context by using a VoiceXML <property> element in your application. This ensures that the setting affects all levels of data logging within the applicable scope: call logs, utterance waveforms, diagnostic logs, and whole call recordings (if applicable).

Voice Platform supports these secure context properties in VoiceXML:

  • swirec.secure_context: Affects recognition logging. Use swirec.secure_context when you expect sensitive information in a user’s response to a prompt—for example, when your application asks for a credit card number.
  • switts.secure_context: Affects TTS logging. Use switts.secure_context when your application has sensitive information in a prompt—for example, when playing back a credit card number for confirmation.

When you need to suppress both recognition and TTS logging—for example, if the user may respond to a credit card confirmation prompt with a corrected number—you must set both parameters, to affect both parts of the interaction.

When you set a secure context via a property in VoiceXML, it applies at the appropriate scope. For example, if you activate secure context for prompts at the beginning of a <field>, it applies throughout the field—including any <filled> elements within the field.

It is recommended that you set the scope of secure context parameters so that they apply only to the specific recognition events or prompts that need to be protected. Suppressing or encrypting too much data makes it very difficult to perform tuning and analysis. It may also affect system performance, as encryption requires additional CPU cycles.

Note: In all cases, Nuance recommends that you test the secure context carefully to be sure that it works as intended, and that sensitive information is not being exposed.

Secure context levels

Both swirec.secure_context and switts.secure_context support three levels of security:

  • open (default): No security is applied—prompt text and recognition results appear in the diagnostic and call logs, and utterance waveforms are recorded.

    To set this level of security explicitly, set the value to “open” (or “0”, which is supported for backwards compatibility).

  • suppress: Utterance waveforms are not recorded, input text capture (for TTS) is suspended, and recognition results in the diagnostic and call logs are suppressed. Voice Platform substitutes the string “_SUPPRESSED” in the logs where sensitive data would appear, and masks the data with silence in the whole call recording (if whole call recording is enabled).

    To set this level, set the value of the secure context property to “suppress” (or “1”, which is supported for backwards compatibility).

  • encrypt: Utterance waveforms are recorded but encrypted, and recognition results in the call logs are encrypted. Voice Platform substitutes the string “_ENCRYPTED” in the call logs where sensitive data would otherwise appear, and appends the encrypted entry to the end of the call log. In diagnostic logs, sensitive information is suppressed, not encrypted.

If whole call recording is enabled, the item is masked with silence in the recording. Encrypted items can later be decrypted by authorized personnel, using a private key. See Setting up encryption.

To set this level of security, set the value of the secure context property to “encrypt”. Voice Platform also supports separate parameters for encrypting an entire whole call recording (see Encrypting whole call recordings).

Note: To use encryption with the secure context properties, you must first generate a public key and refer to it in your application’s session.xml file (encryption_key parameter). If you use the encrypt option without specifying a public key, Voice Platform generates an alarm and encrypted data is lost.Events are replaced with _ENCRYPTED in the call logs, but no encrypted data is written to the log. The *.wav.enc audio files are generated, but do not contain audio.

The effects of each level on logging are summarized in this table:

Secure context:

open

suppress

encrypt

Call logs

content appears in log

_SUPPRESSED

_ENCRYPTED (The encrypted material is inserted as a separate item in the call log.)

Utterance waveform

recorded

not recorded

encrypted (*.wav.enc)

Diagnostic logs

content appears in log

_SUPPRESSED

_SUPPRESSED

Whole call recording

segment recorded

masked with silence

masked with silence

To encrypt an entire whole call recording, you must use the wcr_encrypt or server.rtp.wcr.encrypt parameters. For more information, see Encrypting whole call recordings.

Level

Call logs

Utterance waveforms (applies to recognition only)

Diagnostic logs

Whole call recording

open

Content appears in log

Recorded

Content appears in log

Segment recorded

suppress

_SUPPRESS

Not recorded

_SUPPRESSED

Masked with silence

encrypt

_ENCRYPTED (The encrypted material is inserted as a separate event in the call log.)

Encrypted (*.wav.enc)

_SUPPRESSED

Masked with silence (If you are already encrypting the entire whole call recording, individual items are not masked with silence when you set an individual secure_context to the encrypt option. However, the mute_wcr properties do mask item with silence as normal.)

Setting secure context for a recognition

To suppress the logging of sensitive voice or DTMF input during a recognition, set the swirec.secure_context property as a child of the <field> element:

<field name="secure_reco" type="digits?length=10">
    <property name="swirec.secure_context" value="suppress"/>
    <prompt>Please say your ten digit credit card number. </prompt>
</field>

The text returned by the recognizer in the SWI_literal and SWI_meaning keys is not logged, and the utterance is not recorded. However, the prompt is logged as normal (unless you also use the switts.secure_context property, as described in the next section).

The corresponding SWIrcnd event in the call log entries will have SECURE set to TRUE, and several other items in the entry will be set to _SUPPRESSED:

TIME=20110120134538382|CHAN=0a0314b4_000019c8_4b574f3a_0008_0001|EVNT=SWIrcnd|SECURE=TRUE|RSTT=ok|RENR=prun|ENDR=itimeout|NBST=2|RSLT=_SUPPRESSED|RAWT=_SUPPRESSED|SPOK=_SUPPRESSED|GRMR=GURI0|KEYS=_SUPPRESSED|CONF=946|RAWS=-2419.872070|RSLT=_SUPPRESSED|RAWT=_SUPPRESSED|SPOK=_SUPPRESSED|GRMR=GURI0|KEYS=_SUPPRESSED|...|WVNM=_SUPPRESSED|...

The corresponding NUANwvfm event in the call log will have PLAYABLE set to _SUPPRESSED:

TIME=20100120134538382|CHAN=0a0314b4_000019c8_4b574f3a_0008_0001|EVNT=NUANwvfm |PLAYABLE=_SUPPRESSED|UCPU=0|SCPU=0

Setting secure context for a prompt

To set a secure context for a prompt or DTMF output without affecting how the recognition itself is logged, set the switts.secure_context property:

<field name="confirm" type="boolean">
    <property name="switts.secure_context" value="suppress"/>
    <prompt>I heard, <say-as type="digits">
      <value expr="secure_reco"/></say-as></prompt>
      <!-- Optionally, put other code here -->
</field>

In this example, logging is suppressed for the prompt only, so the user account number collected in the previous field is still not logged. However, the user’s reply to the prompt is logged and the utterance recorded as normal (unless you set the swirec.secure_context property to suppress too, in which case the recognition is also suppressed).

The corresponding NVOCinpt event in the call log will have SECURE set to TRUE, and several other items in the entry will be set to _SUPPRESSED as shown here:

TIME=20100120134532444|CHAN=0a0314b4_000019c8_4b574f3a_0008_0001|EVNT=NVOCinpt| SECURE=TRUE|URI=_SUPPRESSED|DATA=_SUPPRESSED|TYPE=application/ synthesis+ssml|RESULT=TTS_SUCCESS

Setting secure context in a grammar

The swirec.secure_context and switts.secure_context properties represent the most convenient option for setting a secure context, because they can be set at the field level. However, for a voice grammar (that is, not a DTMF grammar) you can use the GrXML <meta> element within the grammar as a Boolean, to suppress the recognition results from the log:

<?xml version='1.0' encoding='ISO-8859-1'?>
<grammar xmlns="http://www.w3.org/2001/06/grammar" version="1.0" 
    xml:lang="en-US" root="rule1" tag-format="swi-semantics/1.0">
<meta name="secure_context" content="1"/> 
    <rule id="rule1" scope="public">
    ...
    </rule>
</grammar>

Note that encryption is not supported at the grammar level. When you set secure_context in a <meta> element, the only permitted values are “1” (suppress) and “0” (open).

This setting is valid each time the grammar is invoked, and affects call log and waveform logging as described under Setting secure context for a recognition. However, this method is risky, as it may be ignored under many circumstances:

  • A secure_context within a grammar has no effect on whole call recording.
  • A secure_context within a grammar has no effect on the nss.log diagnostic log.
  • If the application specifies a swirec.secure_context property in the VoiceXML, this setting automatically takes precedence over any secure_context set in a grammar.
  • Within a grammar, secure_context is a recognition-time parameter, subject to the rules of parameter precedence for grammars. This means the setting may be ignored if a setting with higher precedence appears in an applicable parameter grammar.
  • The setting will be ignored if the grammar is imported by another grammar with a different secure_context setting—the parent grammar setting takes precedence.
  • A secure context set via <meta> does not affect the logging of DTMF input. You can only apply a secure context to DTMF input via the swirec.secure_context property. See Setting logging security on DTMF input.

Since it is often ineffective, and does not permit encryption, this method of setting a secure context is not recommended. If you use it, be sure to test it especially carefully.

When set to 1, secure_context overrides the swirec.swiep_suppress_waveform_logging and swirec.swirec_suppress_waveform_logging settings. For more information on these parameters, see Waveform logging.