Telephony Security: News From the Trenches

Industry UpdateEnterprise Perspective

Scope and DefinitionsNot just automated calls

Scams, spam, TDOS, sales calls

Faxingyes, this still exists, and yes, it’s used for all sorts of things that people don’t want

It’s not just about the robots

StatisticsAverage, year-over-year increase in unwanted calls: 40-50% (all states)

Increase since 2016: 150% (all states)

For New Orleans only:2019: 457,665,4002018: 435,187,3002017: 304,409,0002016: 235,432,000

https://robocallindex.com/history/cities

5.7 Billion Calls in OctoberAlex Quilici, YouMail CEO,

"It's hard to imagine, but we are still on pace to wind up with nearly 60 billion calls to U.S. consumers this year."

Legislation

Compromise bill expected to pass both chambers Dec 2019

Passed by the House 429-3Passed by the Senate 97-1

Caller IdentificationSomehow, users got the idea that callerID was authoritative and correct.

It never was- it was built for a closed network of trusted providers.

Effectively, callerID is useless.

Can we (re)build trust, and is valid caller ID enough?

Three guesses on who this call was from

Caller Identification

Was a voice call really necessary?(no)

Note that the text message uses short codes

Public safety folks- if you want people to answer your calls, use valid CID

Mantra 1

All Caller ID is spoofed

Mantra 2

VoIP is neither necessary nor sufficient for Caller ID spoofing

It just made it cheap and easy and available to the masses

Caller IdentificationWhy is it useless?

Like so much in technology, initial deployment based on trust and security-through-obscurity.

Technology Deployment schedule1. Add Feature2. Profit3. ???4. “Wow, this can be abused?!”5. Attempt to secure feature

Because phone calls are full duplex, silly. (see Mantra #1)

Caller IdentificationMaking it Useful

Labeling a call scam, unwanted, annoying, ‘robocall’ is complicated and may involve a value judgment of the content of the call and intention of the caller

There are backend services and user apps that will attempt to rate a call as ‘scam likely’ based on analysis of multiple data points

The key point of information we’re talking about today:

Is the calling ID valid?

STIR/SHAKEN• STIR - Secure Telephony Identity Revisited

•IETF, RFC 8224 and others• SHAKEN - Secure Handling of Asserted information using toKENs

•ATIS/SIP Forum IP-NNI Task Force• SHAKEN is the framework within which STIR is implemented• Industry effort to verify and validate calling party identity• Carrier implementation in progress

• Significant progress for intra-carrier calls•Eg- AT&T claims 100% of on-net calls verified

• inter-carrier testing continues•Eg- bandwidth.com having weekly interop calls

• FCC deadline of December 2019

STIR/SHAKENOverview

• Establish a three-level indication of the trust level of originating caller ID• Doesn’t (can’t) indicate if the call is a scam, pre-recorded, one-ring, etc call• Similar in concept to SSL public key infrastructure, but “tighter”

• Hundreds of SSL Certificate Authorities•Do you really trust each and every one of the 149 root CAs in Firefox?

• SHAKEN will have a limited number of controlled CAs•The FCC established the Governance Authority

• Run by ATIS (Alliance for Telecommunications Industry Solutions) as Secure Telephone Identity Governance Authority (STI-GA)

STIR/SHAKENGovernance

•STI-Governance Authority will:• Define rules governing certificates• Select the Policy Administrator

•(completed, run by iconectiv)•Policy Administrator

•Will approve CAs and ensure policy compliance• Validates that service providers are authorized to obtain STI Certificates•Will issue “Service Provider Code” (SPC) tokens

•SPs uses these tokens to request intermediate certificate from CA•Maintains a secure list of all authorized STI-CAs and Certificate Revocation List (CRL)

FCCSTI-GA

STI-CA

STI-CA

service provider

service provider

STI-PA

STIR/SHAKENAttestation Levels

• Level A• Full Attestation.

• Carriers knows the calling party, knows the calling party has authority to originate calls using the specified number*.• Has a direct, authenticated relationship with the customer

• Example- retail customer registered to or directly connected to carrier’s switch. The carrier owns/holds the number•Exact policies are up to each service provider, but it is in the service providers best interest not to assign Level A to unknown callers•Most work in this area

*Doesn’t necessarily mean the call is coming from the displayed number, only that customer has the authority to use it.

STIR/SHAKENAttestation Levels

• Level B• Partial Attestation.

• Carrier knows the customer, but can’t (fully) verify the originating number.• Example- enterprise PBX• Not much discussion at this point• Can a customer contractually require a service provider to assign Attestation Level A?

STIR/SHAKENAttestation Levels

• Level C• Gateway Attestation

• Carrier only knows entry point of call into infrastructure• Nothing is known about the caller or the claimed identity

•Why bother with attestation level ‘C’ – it’s effectively what we have today? We know nothing about this call.

• One of the lesser discussed goals for STIR/SHAKEN is quicker inter-carrier call tracing• Signing call establishes transitive UUID making tracing calls much easier

STIR/SHAKENcall origination detail

Ingress SBC Session Control Egress SBC

SHAKEN service

Carrier Network

Calling Party

Next Carrier

1

1. Call arrives at carrier ingress Session Border Controller and passes through carrier network

2. Final SBC sends SIP INVITE to SHAKEN / call authentication infrastructure

1 1

2 3

3. Call Auth responds with a 302/Moved Temporarily which includes Signed Identity Header

4. Call is delivered to the next carrier

4

STIR/SHAKENcall origination detail / HEADER example

X-Identity: eyJhbGciOiAiRVMyNTYiLCJwcHQiOiAic2hha2VuIiwidHlwIjogInBhc3Nwb3J0IiwieDV1IjogImh0dHBzOi8vY2VydGlmaWNhdGVzLmNsZWFyaXAuY29tL2IxNWQ3Y2M5LTBmMjYtNDZjMi04M2VhLWEzZTYzYTgyZWMzYS83Y2M0ZGI2OTVkMTNlZGFkYTRkMWY5ODYxYjliODBmZS5jcnQifQ.eyJhdHRlc3QiOiAiQSIsImRlc3QiOiB7InRuIjogWyIxNDA0NTI2NjA2MCJdfSwiaWF0IjogMTU0ODg1OTk4Miwib3JpZyI6IHsidG4iOiAiMTgwMDEyMzQ1NjcifSwib3JpZ2lkIjogIjNhNDdjYTIzLWQ3YWItNDQ2Yi04MjFkLTMzZDVkZWVkYmVkNCJ9.S_vqkgCk88ee9rtk89P6a6ru0ncDfSrdb1GyK_mJj-10hsLW-dMF7eCjDYARLR7EZSZwiu0fd4H_QD_9Z5U2bg;info=<https://certificates.clearip.com/b15d7cc9-0f26-46c2-83ea-a3e63a82ec3a/7cc4db695d13edada4d1f9861b9b80fe.crt>alg=ES256;ppt=shaken

Encoded SIP header

{"attest": "A","dest": {

"tn": ["14045266060"

]},"iat": 1548859982,"orig": {

"tn": "18001234567"},"origid": "3a47ca23-d7ab-446b-821d-33d5deedbed4"

}

Decoded SIP header

attest – attestation level (A, B, or C)dest – destination telephone number (called party)iat – Issued At (JSON NumbericData (eg, unix Epoch)orig – originating telephone number (calling party)origid – origin identifier. UUID issued when and where the call enters the STIR/SHAKEN infrastructure

STIR/SHAKENcall verification/termination detail

Ingress SBC Session Control Egress SBC

SHAKEN service

Carrier Network

Called Party

Previous Carrier

1

1. Call arrives at carrier ingress SBC from previous carrier

2. SIP INVITE sent to SHAKEN infrastructure

4 4

2 3

3. Call Auth responds with a 302/Moved Temporarily with verification status (verstat) in P-AI

4. Call is delivered to the called Party-or- policy applied (block, redirect,etc)

4

STIR/SHAKENcall verification/termination Header

P-Asserted-Identity: "Alice" <sip:+17005551212; verstat=TN-Validation-Passed@10.251.151.139;user=phone>

SHAKEN call authenticator adds (or modifies P-Asserted-Identity header

Verification Status field

TN-Validation-PassedTN-Validation-FailedNo-TN-Validation

STIR/SHAKENWhat to do with verstat

• How do you inform customers of trust levels of a call?• Do you tell customers about the trust level of a call?• Legacy CID equipment only supports 16 characters

STIR/SHAKENLegacy?

• What about legacy networks?• Big push for IP NNI

STIR/SHAKENEnterprise

• Is ‘B’ the best level calls from a PBX will achieve?• Can I not contractually request/require a carrier to sign calls as ‘A’• They know what numbers are routing into my PBX

•Will carriers pass X-Identity or verstat to the enterprise? • Can my equipment validate the call?• Not using IP trunks?• Can your border equipment handle the new headers?• How do pass along verification data to endpoints?• Should I pass along verification data to endpoints??• Can an enterprise sign its own calls?

•Will this require an OCN and tokens?

• BCP 38 for E.164 addresses?

Open Questions• Focus has been on Level ‘A’ call flows.• Should we even provide call meta-data to users? • Send suspicious calls to a voice CAPTCHA?•What happens when we make CID spoofing difficult? Where does the “bump in the carpet” move to?

• Stating the obvious- callers want their call answered.•Will we see more sophisticated and persistent attacks against PBXs in order to originate calls from a source with good reputation?