D
Don Y
Guest
Hi,
I'm looking for ideas on how to provide (reasonable) authentication
over the PSTN. CID is too readily spoofed (usually by the very folks
that you want to "avoid"!).
A simple scheme might be to use unique identifiers from a large, sparse
ID-space -- providing the ID (DTMF or voice) would provide an indication
of the user. This has the advantage of being tied to a USER and not
a line/device. It sucks because it requires users to remember a
specific ID (for *each* party that they intend to call!)
A more elaborate scheme could rely on voice-print identification.
Ideally, obtaining a voice print from the party at some "registration"
time. To address "playback" attacks, the caller could be required to
make a statement indicated at the time of the call.
Any sort of call-back scheme falls down because of the possibility
of theft of service that it presents. (It also assumes the user
would be at a fixed "location")
Then, there are a whole set of "class identification" schemes (i.e.,
where the type of caller is needed, not the actual identity -- robocall
prevention, etc.). I figure anything interactive will beat them
("Press <digit_determined_at_time_of_call> now", "How much is <digit1>
plus <digit2>?" etc.)
My goal, here, is to provide an "automated attendant" function -- sort
of an "electronic secretary" that can screen calls intelligently:
- route all calls from political parties to /dev/null
- don't even let the phone *ring* if it's a telemarketer
- when I am asleep, take a message from any of these callers
- whenever <someone> calls, *find* me!
- if Bob calls, tell him I am on my way
- if *I* call, give me access to <whatever>
etc.
Obviously, the cost (inconvenience?) to the caller can vary as the
"value" of the service he/she is expecting.
Thx,
--don
I'm looking for ideas on how to provide (reasonable) authentication
over the PSTN. CID is too readily spoofed (usually by the very folks
that you want to "avoid"!).
A simple scheme might be to use unique identifiers from a large, sparse
ID-space -- providing the ID (DTMF or voice) would provide an indication
of the user. This has the advantage of being tied to a USER and not
a line/device. It sucks because it requires users to remember a
specific ID (for *each* party that they intend to call!)
A more elaborate scheme could rely on voice-print identification.
Ideally, obtaining a voice print from the party at some "registration"
time. To address "playback" attacks, the caller could be required to
make a statement indicated at the time of the call.
Any sort of call-back scheme falls down because of the possibility
of theft of service that it presents. (It also assumes the user
would be at a fixed "location")
Then, there are a whole set of "class identification" schemes (i.e.,
where the type of caller is needed, not the actual identity -- robocall
prevention, etc.). I figure anything interactive will beat them
("Press <digit_determined_at_time_of_call> now", "How much is <digit1>
plus <digit2>?" etc.)
My goal, here, is to provide an "automated attendant" function -- sort
of an "electronic secretary" that can screen calls intelligently:
- route all calls from political parties to /dev/null
- don't even let the phone *ring* if it's a telemarketer
- when I am asleep, take a message from any of these callers
- whenever <someone> calls, *find* me!
- if Bob calls, tell him I am on my way
- if *I* call, give me access to <whatever>
etc.
Obviously, the cost (inconvenience?) to the caller can vary as the
"value" of the service he/she is expecting.
Thx,
--don