Re: ACTION-22 Voice Browser Use Case...

Thanks Brad. I've got a really basic question. Where in the PhoneSpoofing 
scenario is the voice browser? 

          Mez

Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
Lotus/WPLC Security Strategy and Patent Innovation Architect




Brad Porter <brad@tellme.com> 
Sent by: public-wsc-wg-request@w3.org
12/05/2006 05:06 PM

To
Brad Porter <brad@tellme.com>
cc
"W3C Security (Public)" <public-wsc-wg@w3.org>
Subject
ACTION-22 Voice Browser Use Case...






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. 


Brad Porter wrote: 
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.

--Brad

[1] VoiceXML 2.0 Standard Session Variables 
http://www.w3.org/TR/voicexml20/#dml5.1.4