I am currently building a real time video chat healthcare app with opentok api, whose technology is largely built on WebRTC and would like to know how the overall security-aspect is handled.
In short, yes. All WebRTC media streams are encrypted.
Since WebRTC is a working spec, here is what I currently know as of July 8, 2013.
All webRTC streams are encrypted with 128-bit AES. Whether that is sufficient for HIPAA compliance or satisfy other health and technology requirements would require more research and knowledge about healthcare.
For an updated documentation about security for WebRTC I would look at IETF docs.
http://www.ietf.org/rfc/rfc3711.txt
http://www.ietf.org/rfc/rfc5764.txt
Here is the proposed security architecture:
http://www.ietf.org/proceedings/82/slides/rtcweb-13.pdf
Related
If the signalling part of webrtc is handled by sip, is it mendatory that sip signalling has to be encrypted by TLS. Is it mendatory that sip over websocket has be encrypted as TLS
WebRTC uses TLS sessions or QUIC for its signaling transport – both are encrypted in nature. All other avenues for non-encrypted signaling don’t really exist in WebRTC. Theoretically they might work, but some browsers will either block them altogether or require the user to grant access to the camera and microphone on each interaction. Deploying anything serious to production with WebRTC without encrypting signaling for their browser implementations is not a real alternative.
WebRTC “forces” you to encrypt your signaling. What is left out of scope of WebRTC are things like authentication, authorization and identity management. You are free to do as you please in that domain – just make sure to do something here – and not leave this wide open for pranksters or worse.
For native applications on mobile, desktop or embedded – you can do whatever you like. That said, the mindset must be the same – mandatory encrypted signaling.
reference : Best webrtc related blog
i'm developing an android app that must be PCI PA-DSS compliant, my question is about this requirement in the PA-DSS_v3-1 document
3.3.1 Use strong cryptography to render all payment application passwords unreadable during transmission.
let's say i have a "change your pasword" feature in my app that transmits the user's account password over a ssl/tls encrypted connection to the server. Is this encryption sufficient to comply to the requirement? do i need to implement some kind of encryption before sending it through ssl?
thank you.
The PCI standard can be vague at times and a little 'open ended', but from our experience, its quite OK as you have it.
SSL/TLS IS the encryption, just use it for your forgotten password feature and you'll be fine.
I am interested in experimenting with WebRTC data streams as a method of low-latency communication between peers in multiplayer games in the browser, but have read that WebRTC is always encrypted. From http://webrtc-security.github.io/
Encryption is a mandatory feature of WebRTC, and is enforced on all components, including signaling mechanisms. Resultantly, all media streams sent over WebRTC are securely encrypted, enacted through standardised and well-known encryption protocols. The encryption protocol used depends on the channel type; data streams are encrypted using Datagram Transport Layer Security (DTLS) and media streams are encrypted using Secure Real-time Transport Protocol (SRTP).
It seems odd to me to have encryption so tightly coupled in this way. I can think of contexts where mandatory encryption is a hindrance, like multiplayer gaming where data transferred is non-sensitive and having to encrypt/decrypt data is unnecessary overhead, however small. For comparison, WebSockets communication is encrypted further down the stack by TLS if present, but the option of communicating over plain TCP is available as well. Am I misunderstanding this or is there a reason why it was decided that all WebRTC communication must be encrypted?
WebRTC is defining new realm for browsers which was not primarily intended. IMO Accessing camera/microphone rises enough resistance to use the technology solely so mandatory encryption gonna ease it.
The same reason as HTTPS communication is encrypted, they're trying to avoid a middle man to get advantage of the peer to peer communication
I am almost ready to submit a Windows 8 Store app to the store. As part of this process you must answer the question:
Does your app call, support, contain, or use cryptography or encryption?
It goes on to mention these possibilities:
Any use of a digital signature, such as authentication or integrity checking
Encryption of any data or files that your app uses or accesses
Key management, certificate management, or anything that interacts with a public key infrastructure
Using a secure communication channel such as NTLM, Kerberos, Secure Sockets Layer (SSL), or Transport Layer Security (TLS)
Encrypting passwords or other forms of information security
Copy protection or digital rights management (DRM)
Antivirus protection
(emphasis mine.) There are some exemptions:
Password encryption
Copy protection
Authentication
Digital rights management
Using digital signatures
My app was originally a Windows Phone app with limited ability to store or export data locally, so we have functionality to backup to or restore from SkyDrive. (For the purposes of this question the fact that SkyDrive may soon change its name is not relevant.) We put this same capability into the Windows Store app. The connection to SkyDrive is https - in other words we are using SSL.
Does this mean I need an Export Commodity Classification Number (ECCN)? Really?
From this page, Understanding export restrictions on cryptography, it looks like the answer is yes, SSL counts unless you are not transporting content over the wire. But I'm not a lawyer.
Does your app call, support, contain, or use cryptography or encryption?
This question helps you determine if your app uses a type of cryptography that is governed by the Export Administration Regulations. The question includes the examples shown in the list here; but remember that this list doesn't include every possible application of cryptography.
Important When you answer this question, consider not only the code you wrote for your app, but also all the software libraries, utilities and operating system components that your app includes or links to.
Any use of a digital signature, such as authentication or integrity checking
Encryption of any data or files that your app uses or accesses
Key management, certificate management, or anything that interacts with a public key infrastructure
Using a secure communication channel such as NTLM, Kerberos, Secure Sockets Layer (SSL), or Transport Layer Security (TLS)
Encrypting passwords or other forms of information security
Copy protection or digital rights management (DRM)
Antivirus protection
For the complete and current list of cryptographic applications, see EAR Controls for Items That Use Encryption.
Is the cryptography or encryption limited to one or more of the tasks listed here?
If you answered yes to the first question, then the second question lists some of the applications of cryptography that are not restricted. Here are the unrestricted tasks:
Password encryption
Copy protection
Authentication
Digital rights management
Using digital signatures
If your app calls, supports, contains, or uses cryptography or encryption for any task that is not in this list then your answer to this question is No.
I had an idea for a fitness mobile app and I have been developing applications based on this idea for iPhone (Obj-C based), Android (java based), WebOS (html5 based) and Nokia Qt.
I now need to provide authentication to the users of my application. The server is a typical LAMP system. I would like the users of my mobile application to log in to the server seamlessly and securely.
I am not really a web programmer and hence would appreciate ideas on how I can go about providing authentication. I've heard about OpenID...but I am not sure if it can be used for authenticating mobile clients. Some one mentioned OAuth but I am not sure if a) it would work in this use case and b) What if my client does not have a Facebook/Twitter account?
Any ideas will be appreciated!
I have done something similar and used gnuTLS and a x.509 certificate to authenticate from the client side. Its seamless and easy to integrate.
https://idlebox.net/2009/apidocs/gnutls-2.6.6.zip/gnutls_7.html#SEC65
The important thing about using this method for me was that the https connection was just simple method calls and the handshaking process itself would be handled by the gnuTLS library.
My app was an iOS app and i used xcode to do it which was easy. I think it will be easier on the Java side but I am not sure about the Nokia part. The coding is in C and is thus cross platform.
However if you are looking for a iOS based solution i recommend http://developer.apple.com/library/ios/#samplecode/AdvancedURLConnections/Introduction/Intro.html
But for a cross platform solution that would require the same certificate across all applications and no input or work fro the user, I still suggest gnuTLS and using the x509 certificate.
If you already have a LAMP server somewhere, it should be fairly easy to set implement your own API for password authentication -- the important thing is that you do it via HTTPS! (so the user-ids / passwords can not be sniffed). You will need a digital certificate (CERT) for your web-server.
On your LAMP system you can keep the user data in it's database. Your LAMP server should also allow to create a local user account (of course).
You can use this solution either separate or together with OpenID or OAuth!
That means, if your client doesn't have Facebook or Twitter, they can still create an account on your LAMP server.
http://en.wikipedia.org/wiki/OAuth