A VoiceXML voice browser could be used to implement the automated
voice-service in the scenarios described below.
As I mentioned in the first email I sent about Action 22...
"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."
Most of our discussions in the visual world require the user to first
trust-the-browser, then trust the security context data that the browser
is providing. This works because presumably people are using one of
only 4 browsers in the world -- IE, Firefox, Opera, Safari. In the
voice world, given you don't even know you're interacting with a
browser, there isn't much context by which you would trust the browser.
In fact, it is highly likely that many of the folks in this group
(especially US-based) have happily hyperlinked around in a voice browser
without knowing it. If you've received a flight notification call from
Orbitz, called 1-800-GOFEDEX, or 411 on Cingular, or 1-800-FANDANGO, or
800-555-1212, or E*TRADE, Fidelity, Wells Fargo, American Express, or
Merrill Lynch customer service, you've interacted with a voice browser.
And these are just a few...
--Brad
Mary Ellen Zurko wrote:
>
> 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_