Tag: webrtc security

security for WebRTC applications

—The general goal of security is to identify and resolve security issues during the design phase so they do not cost service provider time, money, and reputation at a later phase. —Security for a large architecture project involves many aspects, there is no one device or methodology to guarantee that an architecture is now “secure” —Areas that malicious individuals will attempt to attack include but are not limited to:

  • Improperly coded applications
  • Incorrectly implemented protocols
  • Operating System bugs
  • Social engineering and phishing attacks

—As security is a broad topic touching on many sections of WebRTC this section is not meant to address all topics but instead to focus on specific “hot spots”, areas that require special attention due to the unique properties of the WebRTC service. —There are several security related topics that are of particular interest with respect to WebRTC.  They can be grouped into the following areas:

  1. Identity Management
  2. Browser Security
  3. Authentication
  4. Media encryption

The are discussed in detail below :

Identity Management

—Support of WebRTC should not increase security risk to telecom network. —Any device or software that is in the hands of the customer will be compromised, it is just a mater of time

  • All data received from untrusted sources (i.e. all data from customer controlled devices or software) must be validated.
  • Any data sent to the client will be obtained by malicious users

—Provide exceptional protection for our customer’s data and make all reasonable attempts at protecting the customer from their own mistakes that may compromise their own systems. —Ensure that the new service does not adversely impact the data security, privacy, or service of existing customers.

Browser SECURITY

—Specific security concerns include:

—Cross-site scripting (XSS)

a type vulnerability typically found in Web applications (such as web browsers through breaches of browser security) that enables attackers to inject client-side script into Web pages viewed by other users.

  • A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same origin policy.
  • Cross-site scripting carried out on websites accounted for roughly 80.5% of all security vulnerabilities documented by Symantec as of 2007 according to Wikipedia.
  • Their effect may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site’s owner.

—As the primary method for accessing WebRTC is expected to be using HTML5 enabled browsers there are specific security considerations concerning their use such as; protecting keys and sensitive data from cross-site scripting or cross-domain attacks, websocket use, iframe security, and other issues. —Because the client software will be controlled by the user and because the browser does not, in most cases, run in a protected environment there are additional chances that the WebRTC client will become compromised. This means all data sent to the client could be exposed.

  • keys
  • hashes
  • registration elements (PUID etc.)

—Therefore additional care needs to be taken when considering what information is sent to the client, and additional scrutiny needs to be performed on any data coming from the client.

—Clickjacking

(User Interface redress attack, UI redress attack, UI redressing) is a malicious technique of tricking a Web user into clicking on something different to what the user perceives they are clicking on, thus potentially revealing confidential information or taking control of their computer while clicking on seemingly innocuous web pages. It is a browser security issue that is a vulnerability across a variety of browsers and platforms, a clickjack takes the form of embedded code or a script that can execute without the user’s knowledge, such as clicking on a button that appears to perform another function. —Compromised personal computer with installed adware, viruses, spyware such as trojan horses, etc. can also compromise the browser and obtain anything the browser sees.

—Authentication

—Authentication happens on different levels

—End user Authentication:

through UID ( unique ID ) of USER

—Device Authentication

  • —SIM enabled devices follow standard IMS-AKA authentication
  • —Non-SIM enabled “devices” are authenticated using user authentication

—Application Authentication

  • —Model mirrors current application onboarding procedures.
  • —Application developers need to establish service agreement
  • —Client_Id secrets are exchanged as part of this process.
  • Use  security gateway for authenticating applications

Media Encryption

—Primary issue with supporting DTLS is it can put a heavy load on the SBC’s handling encryption/decryption duties. —Interworking DTLS-SRTP to SDES is CPU intensive

  • SRTP from DTLS-SRTP end flows easily
  • SRTP from SDESC end requires auth+decrypt, and encrypt+auth

—Reason:  DTLS-SRTP handshake has both ends choose “half” of the SRTP key —The Encrypted Key Transport (EKT) proposed by Cisco solves this problem and provides additional security. —Recommendation is to use DTLS-SRTP with EKT enhancements

  • Note: In order to avoid potential security issues, the SRTP authentication tag length used by the base authentication method must be at least ten octets.

………………………………………………………………………………………………………………….. —