Disruptive Telephony

For those who use WhatsApp, you may have noticed that your messages are secure and private, thanks to the encryption that is used. But what is encryption, and why is it so important?

Encryption is a process of scrambling information so that only the intended recipient can read it. Essentially, it takes the data you’re sending and scrambles it using a mathematical algorithm. To unscramble the data, you need a key, which is known only to the sender and the receiver.

WhatsApp uses end-to-end encryption, which means that your messages are encrypted on the sender’s device, travel securely to the receiver’s device, and remain encrypted until the receiver reads them. This means that no one – not even WhatsApp themselves – can see the messages you’re sending.

This is an important feature for anyone concerned about their privacy, especially in an era of increased surveillance. With WhatsApp’s encryption, you can be sure that your messages will stay safe, secure, and private.

WhatsApp is also working to improve their encryption, with plans to add a feature known as “Perfect Forward Secrecy”. This feature will generate a new encryption key for each message you send, ensuring that if one key is ever compromised, the others will remain safe.

Encryption is an important part of keeping our messages secure, private, and confidential. Thanks to WhatsApp’s use of encryption, we can be sure that our messages are safe and secure.

 

— A second version — 

In the age of increasing concern over privacy and security, end-to-end encryption has become an essential part of secure communication. WhatsApp, the popular messaging and voice-over-internet-protocol (VOIP) application, has been at the forefront of this movement, using the strong encryption protocols to keep users' conversations secure.

WhatsApp uses the Signal Protocol, an open-source encryption protocol developed by Open Whisper Systems, for its communications. The Signal Protocol is considered to be one of the most secure encryption protocols available, and is used by other popular messaging services such as Facebook Messenger, Google Allo, and Skype.

Using the Signal Protocol, WhatsApp transmits messages between users in an encrypted form, meaning that only the sender and recipient can see the contents of the message. This makes it impossible for third-party entities, such as government agencies or hackers, to read or intercept the messages. The encryption is also applied to all media messages, including photos, videos, and audio recordings, as well as group messages.

WhatsApp also uses a two-factor authentication system for added security. This means that users must enter a code sent to their phone before they can access their account. This provides an extra layer of protection that makes it difficult for hackers to gain access to user accounts.

Overall, WhatsApp's use of encryption is a great step forward in protecting users' privacy and security. The Signal Protocol provides a secure communication medium, and the two-factor authentication system helps ensure that users' accounts are secure. It's no wonder that WhatsApp is used by millions of people around the world.

 

— A third version — 

Recently, WhatsApp announced that it is now using end-to-end encryption for all its communications. This means that all messages, pictures, audio and video files sent through the popular messaging app will be encrypted so that only the sender and recipient can view or hear them.

WhatsApp's use of encryption is a huge step forward in protecting user privacy. With end-to-end encryption, even the company itself can't access the content of messages sent through its service, meaning that users can be sure that their conversations remain private. The encryption also makes it much harder for hackers or other malicious actors to intercept messages, protecting users from potential data breaches.

The encryption also has implications for businesses and organizations that use WhatsApp for communications. By securing messages with end-to-end encryption, companies can be sure that their confidential conversations remain private, even if an employee's device is hacked. This added layer of security can help protect businesses from potential data breaches, and also provide a higher level of assurance to customers who are sending sensitive information.

WhatsApp's use of encryption is a welcome move that will help protect user privacy and data security. It's a great example of how technology can be used to improve security and protect user data.

 

— Why three versions? — 

All three of these were “written” by the ChatGPT service using the prompt "Write a blog post about WhatsApp's use of encryption in the style of Dan York”. I just refreshed it to get another version. I used the default settings except for changing the maximum length to 1100

They’re not bad, eh?

The text is not entirely off from what I would normally write on my sites. I put a strikethrough on the last sentence of the first two because those were sentences I don’t think I would ever write. They feel a bit overly promotional. I included them just to show what ChatGPT would produce.

Certainly text like this could generate a quick “first draft” that I could then edit a bit to publish.

Would you have known that I did not write them if I didn’t indicate it was from ChatGPT?

We live in interesting times… 

 

This week I will briefly be in Bucharest, Romania, for the Internet Society's ION Bucharest conference. We've got a great set of sessions on the agenda, including:

• Deploying DNSSEC
• Romanian DNSSEC Case Study
• Let's Encrypt & DANE
• Mind Your MANRS & the Routing Resilience Manifesto
• The Case for IPv6
• IPv6 Success Stories
• What's Happening at the IETF? Internet Standards and How To Get Involved

I will have two roles in the event tomorrow:

• Presenting the "Deploying DNSSEC" technical session.
• Doing the live streaming of the event through the Deploy360 YouTube channel.

I enjoy doing the production of live video streams and so this should be a good bit of fun (it's also intense work in the midst of it).

You can WATCH LIVE starting at 14:00 EEST (UTC+3, or 7 hours ahead of the US East Coast where I live).

The sessions will also be recorded for later viewing.

It will be a short trip for me. I'm currently (Tuesday morning) writing this from the Munich airport. I land in Bucharest tonight. The event is tomorrow - and then I fly home Thursday afternoon.

Despite the short visit, I'm looking forward to it - it should be a great event!

---

An audio commentary on this topic is also available:

---

Photo credit: Nico Trinkhaus on Flickr - CC BY NC

Is it time to use Transport Layer Security (TLS... essentially what we used to call "SSL") to add a layer of trust and security to Voice-over-IP (VoIP) that uses the Session Initiation Protocol (SIP)?

Way back in June 2014, I gave a talk on this topic at the SIP Network Operators Conference (SIPNOC) in Herndon, Virginia. I recorded the audio of the session... but then lost track of the recording. I recently found it and, since much of it is (sadly) still relevant, I decided to release the recording as one of my The Dan York Report audio podcast episodes:

The slides that go with the presentation are available on SlideShare:

You'll see in the slide deck that I also provide some tutorials around DANE and DNSSEC along the way.

Coincidentally, I learned on Facebook over the weekend that my friend Olle Johansson was speaking on this exact topic at the FOSDEM 2016 conference in Brussels this weekend. His slides about SIP & TLS are also available on SlideShare, and he has more recent information - and also the conclusion that we need to use "SIP Outbound" for any of this to work:

Olle's last slide about what we need to do hits on the key points - and I agree with his conclusions.

Let's look at how we can get more TLS used within SIP to bring about a more secure and trusted VoIP infrastructure!

Can we create a "secure Caller ID" for IP-based communications, a.k.a. voice-over-IP (VoIP)? And specifically for VoIP based on the Session Initiation Protocol (SIP)? Can we create a way to securely identify the origin of a call that can be used to combat robocalling, phishing and telephony denial-of-service (TDOS) attacks?

That is the challenge to be undertaken by the "Secure Telephone Identity Revisited (STIR)" group meeting tomorrow morning, July 30, 2013, at 9:00 am in Berlin, Germany, as part of the 87th meeting of the Internet Engineering Task Force (IETF). The meeting tomorrow is a "Birds Of a Feather (BOF)", which in IETF language is a meeting to determine whether there is sufficient interest to create a formal "working group" to take on a new body of work within the IETF. The proposed "charter" for this new work begins:

Over the last decade, a growing set of problems have resulted from the lack of security mechanisms for attesting the origins of real-time communications. As with email, the claimed source identity of a SIP request is not verified, and this permits unauthorized use of source identities as part of deceptive and coercive activities, such as robocalling (bulk unsolicited commercial communications), vishing (voicemail hacking, and impersonating banks) and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments). This working group will define a deployable mechanism that verifies the authorization of the calling party to use a particular telephone number.

The agenda for tomorrow's STIR meeting begins with a presentation by Henning Schulzrinne, now CTO of the US Federal Communications Commission (FCC) but also a long-time IETF participant and one of the co-authors of the original RFC 3261 specification for SIP. Henning will be laying out the problem statement and there will be a discussion of the proposed scope of the IETF work. He'll be followed by presentations of potential solutions by Jon Peterson, Eric Rescorla and Hadriel Kaplan and then a discussion of the proposed charter and the work to be done. Given the intense debate that has occurred on the STIR mailing list over the past weeks I expect tomorrow's session to be one where some points will receive a great amount of passionate debate and discussion. (If you are interested in listening in or participating remotely in tomorrow's STIR meeting, see the information later in this article.)

Revisiting Previous SIP Identity Work

As some background, the Internet Architecture Board (IAB) laid out some of the challenges to "secure origin identification" in IP-based communication last November and took a very high-level look at the overall issue. Next, in preparation for what became this STIR effort, Jon Peterson, Henning Schulzrinne and Hannes Tschofenig authored a draft problem statement and requirements document.

The "Revisited" part of the group name is a nod to the fact that this whole issue of asserting "identity" has been explored within the SIP community in the past. Way back in 2006, RFC 4474 defined what has been called "SIP Identity" and provided a method for cryptographically signing certain SIP headers to identify the origin of a call. Unfortunately, RFC 4474 turned out not to work well with the way SIP was actually deployed and so usage has been virtually non-existent. An effort to update that document, what is called "RFC4474bis", has also been proposed and some of those ideas may be incorporated into the new proposed work for the STIR group.

There have also been other efforts such as the "P-Asserted-Identity (P-A-I)" defined in RFC 3325. The challenge here, though is that theoretically P-A-I is supposed to be limited to usage within a trusted network, although in practice it may be seen by other networks. There have also been several efforts to define or document identifiers for billing purposes (including my own P-Charge-Info) although these efforts are trying to solve a slightly different problem.

The point here really is that the STIR effort is drawing upon a rich body of "SIP identity" work that dates all the way back to some early drafts in 2002. Much thought has been given to this issue and many of the people involved with STIR have also been involved with earlier efforts and understand well some of the challenges faced by that past work.

An Important Difference

One important difference between STIR and earlier "SIP identity" efforts is that initially the STIR effort is only focused on telephone numbers. The draft charter explicitly states this:

As its first work item, the working group will specify a SIP header-based authorization mechanism to verify the originator of a SIP session is authorized to use the claimed source telephone number, where the session is established with SIP end to end. This is called an in-band mechanism. The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation.

and later:

Expansion of the authorization mechanism to identities using the user@domain form deferred since the main focus of the working group is to develop a solution for telephone numbers.

Previous "identity" work was also undertaken to include a "SIP URI" or "SIP address" and while the ultimate STIR mechanism (or a variant thereof) might also work for SIP URIs, the focus in this initial work is all around securing the origin identification of telephone numbers.

This initial focus makes a great amount of sense given that so much of the SIP traffic today is a result of telecom service providers moving their regular calls to telephone numbers off of the legacy PSTN networks and over to IP networks where they use SIP. Additionally, a great amount of the "problem" traffic seen in VoIP today can be created by attackers who use simple VoIP software to generate their calls to regular telephone numbers.

Remotely Participating In Tomorrow's STIR BOF

If you are interested in participating in the meeting (or at least listening in) on Tuesday, July 30, the meeting will go from 9:00 - 11:30 local time in Berlin, Germany. Berlin is in Central European Summer Time (CEST) which is UTC+2 (and 3:00 am US EDT / midnight US PDT for my friends back in the USA).

You can hear the audio stream at:

• http://ietf87streaming.dnsalias.net/ietf/ietf874.m3u

You can also join the Jabber chat room at:

• xmpp:[email protected]

The slides and other meeting materials can be found at (and note that materials may not be uploaded until shortly before the session and so you may need to refresh your browser):

• http://datatracker.ietf.org/meeting/87/materials.html#stir

Alternatively you can use the "MeetEcho" conferencing system that integrates the audio, the slides and the Jabber chat room at:

• http://www.meetecho.com/ietf87/stir

More information about participately remotely can be found on the IETF 87 Remote Participation page.

To get the most out of the meeting, you'll also want to read these three Internet Drafts that will be part of the solutions being discussed:

• draft-peterson-secure-origin-ps
• draft-rescorla-stir-fallback
• draft-kaplan-stir-cider

.... and be prepared for what should be a LIVELY discussion!

If you are unable to participate remotely, the session will be recorded and you will be able to listen to the archived audio stream, view the Jabber chat logs and also playback the MeetEcho recording.

Getting More Involved

Beyond listening to tomorrow's BOF session, the best way to get involved - either to actively participate or to at least monitor the effort - is to join the STIR mailing list at:

https://www.ietf.org/mailman/listinfo/stir

The list is open to anyone to join. There are no membership or corporate requirements or fees - anyone with an email address may participate.

WARNING! - As can be seen in the list archive, there is currently a large volume of discussion and it will probably continue for some time. If you do join the mailing list you may want to consider setting up rules to sort the STIR email into a folder - or just prepare for the volume to be added to your inbox.

The other way to be involved is to monitor and read the documents that are created for the STIR effort. Newer documents are being created with "stir" in the document name and so they can be easily found at:

http://datatracker.ietf.org/doc/search/?name=stir&activedrafts=on

Other documents that are useful to understand this effort are linked to earlier in this article and can also be found in the text of the proposed STIR charter. After tomorrow's STIR BOF session there will be more information about how the effort will proceed within the IETF. The meeting tomorrow should result, I expect, in the recommendation to go ahead with formally creating a working group and undertaking this work, but we'll see what outcome occurs.

Can a method of secure origin identification for SIP-based VoIP calls be created? Given that basically all telecom traffic is in the process of moving to be based on IP, the need for a secure origin identifier is very clearly here - and many of us do believe we can develop a system that will work in today's environment.

What do you think? Are you ready to join in and help?

---

Update: Added the additional charter text about "Expansion of the authorization mechanism to identities..."

---

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• following me on App.net
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

One of the conferences I've found most interesting each year is the SIP Network Operators Conference (SIPNOC) produced by the SIP Forum, a nonprofit industry association. Part of my interest is that it is only an educational conference, i.e. there's no massive exhibit floor or anything... it's all about education. It also brings together pretty much all the major players in the "IP communications" space - certainly within North America but also from around the world.

I'll be there this week in Herndon, Virginia, talking about how VoIP can work over IPv6 and how DNSSEC can make VoIP more secure. The sessions I am directly involved with include:

• Panel Discussion: Anatomy of a VoIP DMZ
• VoIP Security BOF
• Panel Discussion:  IPv6 and SIP - Myth or Reality?
• Who Are You Really Calling? How DNSSEC Can Help

There are quite a range of other topics on the SIPNOC 2013 agenda, including a number of other talks related to security.  

It should be quite a good show and I'm very much looking forward to it.  I'm particularly looking forward to my "DNSSEC and VoIP" talk on Thursday as that is a topic I've not presented on before... but I think there is some quite valuable potential about using DNSSEC with VoIP.

If you are there at SIPNOC this week, please do say hello!

P.S. While SIPNOC is not being livestreamed, you may find some people tweeting using the hashtag #SIPNOC.

---

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• following me on App.net
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

Fascinating news today out of Oracle that they have purchased Acme Packet in a transaction estimated to be around $2 billion US. For those of you not really tracking the VoIP security space, Acme Packet is probably the world's largest vendor of "session border controllers (SBCs)", devices that are used to securely and reliable interconnect VoIP networks. SBCs also provide a very important role in helping with interoperability of Session Initiation Protocol (SIP) signaling between the SIP products and networks of different vendors.

As Andy Abramson writes, the fascinating aspect of this acquisition is this:

This is an interesting grab by one of the tech world's true giants because it sqaurly puts Oracle into a game where they begin to compete with the giants of telecom, many of whom run Oracle software to drive things including SBC's, media gateways and firewall technology that's sold.

This acquisition does put Oracle VERY firmly into the telecom sector at a carrier / large enterprise level, as Acme Packet's products are widely used within that tier of companies. As the news release notes:

"The company's solutions are deployed by more than 1,900 service providers and enterprises globally, including 89 of world's top 100 communications companies."

Acme Packet has also long been recognized as a leader by analyst firms such as Gartner. People from Acme Packet, in particular Hadriel Kaplan, have also been extremely involved with industry efforts such as the SIP Forum and standards activity in the IETF.

As far as integration, Oracle already has a wide array of "communications" products, including several unified communications (UC) products that could potentially interact with Acme Packet products extremely well. Beyond all of that, though, this acquisition will have Oracle being a strong player in providing telecom infrastructure as we continue to collectively move to basing all our communications on top of IP.

Congratulations to my friends at Acme Packet and Oracle... and I wish them the best as they proceed down the path to completing this acquisition.

More information here:

• Oracle news release
• Oracle page about the acquisition
• A letter from Acme Packet CEO

---

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

For those interested in telecommunications security, today's (Dec 2, 2011) VoIP Users Conference (VUC) call at 12 noon US Eastern will cover the recent arrests of 4 Philippine men who defrauded AT&T of close to $2 million and were employed by an alleged terrorist organization who was using the proceeds of the scam to fund their activities.

Eric Klein of Humbug Labs will be the guest on the VUC call discussing this and other fraud issues. It should be an interesting discussion.

You can join the live call via SIP, Skype or the regular old PSTN. There is also an IRC backchannel that gets heavy usage during the call. It will be recorded so you can always listen later.

---

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

Want to see the dark side of mobile apps? Just read this great bit of research from Troy Hunt:

Secret iOS business; what you don’t know about your apps

As people have noted in the comments, "iOS" (Apple's operating system for iPhones and iPads) is purely the platform Troy Hunt did his research on... but he's really talking about issues with mobile applications.

I'm my unfortunately sure that these type of issues will also be there on apps on Android and probably on other mobile operating systems from Microsoft, RIM, WebOS, etc.

These are application design issues.

The article starts off with the incredibly inefficient case of stuffing large images from "regular" websites down the mobile pipe to the phone... and then simply "resizing" them with "width" and "height" attributes. This is just laziness"efficiency" on the app developers part in that they are simply "repurposing their existing content" for a mobile audience, i.e. it's too much work/effort for them to create and track a separate smaller image for a mobile environment so they will just send you the larger one and eat up your data plan bandwidth.

But Troy Hunt goes on to talk about far worse issues... he calls out the analytics sent back to Flurry.com in particular (and there are other similar players out there) that report what the user is doing. I agree with Troy Hunt's comment that where this gets "creepy" for me is not so much reporting data back for one application, but rather that all this data is being aggregated across applications inside of Flurry's databases.

And then the truly scary issue of how little security some applications use to protect login credentials (i.e. NONE!) or to protect confidentiality of the information people are seeing.

As Troy Hunt points out with regard to the Facebook app for iOS:

Unfortunately, the very security that is offered to browser-based Facebook users is not accessible on the iPhone client. You know, the device which is most likely to be carried around to wireless hotspots where insecure communications are most vulnerable.

Mobile devices are being brought to the worst possible WiFi environments... and per this article seem to have some awfully insecure apps running on them.

Every mobile developer needs to read this article - and start looking at how to secure their apps!

P.S. Thanks, Troy Hunt, for writing this piece!

---

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

Only 40% of Canadian cell phone users password-protect their phones or use other privacy options, a survey by Canada's privacy commissioner found. The results of the 2000-person survey were released in August and written up in a Globe And Mail piece entitled "How private is that text message?".

When I saw the headline, I honestly thought it was going to be something about the security of SMS messages... but in fact it was about the security of the cell phones themselves. If the phones aren't secured then someone can go in and look at your text messages. Ergo... the link-bait title of the article. (And yes, it got me to look.)

Still, it had some interesting data points such as the fact that the users from age 18 to 34 were the ones most likely to use privacy tools, which is good to see, since they are probably the ones pumping the most information out online.

Nice to see, too, that 82 percent did not think police should have access to your online usage info without a warrant.

I was surprised, in all honestly, about the 40% number... I actually might have thought of it being lower as I know MANY people who don't password-protect their phones mostly because of the "inconvenience" of having to enter the password to get into the phone.

And in truth the % who password-protect their phones may be lower... the article says that "only four in 10 people password-protect their phones or adjust privacy settings on personal-information sharing via downloaded applications". The number of people who adjust privacy settings - but don't password-protect their phone - may be driving that % up.

I wonder what a survey like this might find in the United States?

Do you password-protect your phone? (I do)

---

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

If any of you will be in Chicago next week, October 4-6, 2011, for the 7th Annual Real-Time Communications Conference & Expo, I'll be there on the 5th and 6th as a speaker.

I'll be speaking twice. First on Wednesday the 5th at 4pm on "The Current State of VoIP Security", wearing my VOIPSA hat and leading off a series of talks about security. I'll be providing an overview of the main threats to VoIP and communications security in general, leading the way into the two more specific talks following mine.

I'm rather excited that my second session will be my first public appearance wearing my new Internet Society hat (if you are not aware, I've posted details about my recent move) and will of course be about IPv6... more specifically "How IPv6 Will Impact SIP And Telecom".

Due to ongoing events on the personal front, I wasn't sure that I was going to make it out there... and quite frankly there's still a chance that I won't... but I should be out there.

If you look at the conference schedule, the speakers include outstanding people involved with so many different aspects of real-time communications. It should be truly an excellent event!

P.S. You can still register if you would like to attend!

---

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---