ACTION-22

Action 22: Produce Voice Browser use case... is assigned to me.

I wasn\'t involved in the discussion at the time this action was generated, so apologies that I didn\'t know I had an action and I\'m going in a little blind on the context for the request. That said, let me lay out some of the differences I see in the voice web experience from a Desktop browser as they pertain to security.

Special Considerations for Web Security in a Voice Browser Context

Differences

* Interaction with a voice browser is often entirely transparent to the end user. He or she has no idea whether the interaction is with a voice browser or any other automated phone application.

* Voice browsers typically have no standard chrome whatsoever. The entire user experience is defined by the application markup. There is some standard context information provided to the application markup (callerid, dialed number) which can be found in 5.1.4 of the VoiceXML 2.0 specification [1].

* Voice browsers have no URL bar. All content must be navigated to via hyperlinking. Bookmarking would be an application-specific feature and is not built into the browser metaphor.

* A highly interconnected voice web is technically feasible, but does not truly exist today. Applications live in their own space and do not contain links outside of their domain.

* For latency reasons, Voice browser deployments often make use of greater presentation markup caching and more separation of dynamic data and presentation data.

* Trust is typically established via the phone number the caller dialed. That said, there is no real reason you can trust the phone number. Trust would be established by the credibility of the source of the phone number (corporate website, phonebook, toll-free directory assistance.) Outbound calls are inherently less trustworthy.

* The search engines in this space are 411 services. 411 data is typically maintained by telcos thorugh their whitepages and yellowpages which usually involves a direct relationship with the business or individual. It is more difficult to publish yourself as a spoof address.

* The phone network tends to have more centralized control with substantially greater regulatory control and legal precedent. For instance, the national do-not-call list generally works where attempts to control email spam haven\'t.

* The costs of answering a spoofed 800# or placing malicious outbound calls are substantially higher than the cost of publishing a spoof website or generating an email.

Similarities

* Voice browsers run in a different trust zone than the web services and databases. Billions of calls a year are handled by voice browsers operated by one company on behalf of another company. These browsers interpret many different companies\' voice applications. As a result a single voice browser may be able to access content and services that the application running on that voice browser is not allowed to access. As a consequence, all the same sandboxing requirements apply.

* Protecting user data and preventing cross-session data leaks is equally critical.

* Voice browsers make heavy use of Ecmascript.

* User authentication is still the responsibility of the web site and not the browser. Cookies are employed. Authentication techniques differ due to the inability to effectively recognize random a strings of letters, digits, caps, and punctuation that is typically found in a typed password. Biometric identification/authentication (voice prints) are more easily integrated into the user experience, though they are not widely deployed.


ACTION-22

Here\'s a story-board version of a use-case...

Also, this link has a relevant use case:

http://www.cknow.com/news/security/PhoneSpoofingAddedtoPhish.html

> Phone Spoofing Added to Phishing
>
> You\'re calmly sitting there and the phone rings. You answer and the person on the other end identifies himself (or herself) as the police and says they are investigating a fraud ring in your neighborhood. The caller-ID checks out and they do have some basic information about you so when they ask you to verify other information like your Social Security Number, credit card number, or other detailed information you agree and give it to them.
>
> You\'ve just become the victim of the latest phishing fraud.
>
> With the ready availability of general information and the ability to make the caller-ID system show a fake caller\'s location, the latest breed of phishers can now use phone spoofing to try to gather more detailed informaiton by making themselves appear like the real thing.
>
> The standard caveats for giving out information still apply even with this newest scam...
>
> * Never give out any personal information in any form to any unsolicited caller.
> * If someone does call asking for information, ask them to put the request in writing and also ask for a call-back number. Chances are you\'ll never hear from the person again, but if you do receive a written request check it out completely before sending anything.
> * As with phone calls, never respond to any unsolicited request for information that comes in via E-mail; no matter how valid it looks.


5.2 Call Lure

Alice is a customer of BobBank. Mallet is an attacker attempting to obtain Alice\'s access credential for the BobBank site by impersonating BobBank via the phone.

Mallet places an outbound call to Alice (and a hundres of other users). The phone number appears to be from a legitimate 800-number service. The voice service introduces itself as BobBank and alerts Alice that for fraud verification purposes, they need to ask her a series of questions. The call also says \"For verification purposes, please enter your account number and numeric pin.\" For further verification, Mallet asks Alice to state her mother\'s maiden name. Finally, the system asks some non-identifying information such as \"Is your checkbook in your possession?\", \"Please state the date of your last ATM transaction?\", \"Please enter the amount of your last ATM transaction?\". The call concludes by saying \"Thank you, your account appears to be in good standing at this time. Goodbye.\"

Mallet also provides an 800 number at the beginning of the transaction that can be used to call back when it is convenient. That 800 number is managed by Mallet and answers asking the same transactions.

Alice and BobBank both have assets at risk. Alice\'s personal information has been compromised and her account may also be compromised at this point. In addition to direct losses due to fraud BobBank may suffer indirect losses due to the need to reissue account numbers, pins, and checkbooks to Alice and increased customer service calls whether or not the attack is successful: Alice may insist on doing all her future transactions at a local branch at significantly higher cost to the bank. Alice may contact customer service to ask about the attack.