Intrepidus Group
Insight

Friday Double Feature – Free Rides and WebCrypto

Posted: September 21, 2012 – 12:40 pm | Author: | Filed under: Uncategorized

This article will cover not one, but two topics!

 NFC For Free Rides and Rooms (on your phone) 

First up is a quick review of the research Corey Benninger and Max Sobell presented in Amsterdam this week. Corey and Max have spent considerable time hacking on NFC related topics. This time, they discovered a flaw in the way many municipalities implement “disposable” fare cards. In many cases there is no central authentication or tracking and the tags are read, and can be written to, via NFC. This allows Max and Corey to overwrite the section of the card that tracks how many rides are left. This is accomplished via their UltraReset Android application. One misconception that should be cleared up is that this is an NFC problem. The Android application was just a convenient method of accessing the data on the fare cards via NFC.

You can see the app in action over at Vimeo.  The relevant coverage can be found at the following places:

WebCrypto first working draft released

The first working draft of the WebCrypto API has been released. Much has been written about cryptography, cryptography for pen testers, cryptography for developers, crypto for everone! Crypto, crypto, crypto. It is a fascinating topic and a required part of having a more safe digital world. Nothing gets a crypto geeks blood’ pumping like a new spec that focuses on crypto. This week there has been quite a bit of discussion about WebCrypto and its API. It is pretty new and is going to need some very careful consideration, but it is my estimation that WebCrypto is not off to a great start. Many of our customers out there writing applications in HTML 5 are going to rely on this API and it does not solve many of the fundamental problems they will face in utilizing cryptography. The WebCrypto API is really only half of the story for most developers, and it really needs to be a complete picture.

My main complaint, aside from some broken and already known to be flawed algorithms and crypto primitives sneaking into the API, is that this API only provides primitives. If you sit a group of developers down and ask them to implement cryptography securely using a library with nothing but primitives such as “AES-128-CBC” and “ECDSA”, chances are very good that you will end up with trivial and not so trivial flaws in the implementation the first go around. Just convincing everyone that authentication is as important as confidentiality can be a real challenge (Hello Padding Oracle!). As a long time software developer I look for APIs that expose just the “tip” of the iceberg in terms of functionality. A truly beautiful API only exposes as much as it needs to and hides the rest. Never is there a time where experienced designers should be hiding details than in a crypto library. For the vast majority of crypto code I have seen, if there was a much simpler API that abstracted out a lot of the common pitfalls and got rid of the insecure and flawed modes and algorithms, my crypto reviews would have been a lot less interesting. Developers need functions that are simple and safe, by default: encrypt(some_data), decrypt(some_data), verify(some_data), sign(some_data). It needs to be almost that simple!

Developers are not (typically) cryptography practitioners, and should not have to make algorithm and primitive choices. Instead when I look at the standard, I see a bunch of primitives! For some examples of APIs done right, check out Bernstein’s NaCl or the Windows Data Protection API (DPAPI). Nate Lawson has also written on this topic, you could take his blog post and the same arguments apply.Even these APIs are too low level for my taste, but it is far better than thrusting a bunch of crypto primitives at developers. And my final problem is that many development teams *will* abstract WebCrypto, and they will do it using JavaScript, which puts us right back in the mess of having to deal with sensitive crypto code written in a language and runtime that is not trustworthy. So really, what are we accomplishing here? DRM for Netflix (via @tqbf)?

That said, this API is a nice set of primitives and it does include some practical things like PBKDF2 (Password Based Key Derivation Function 2), which will be really useful for the applications that need it. Explaining to everyone what PBKDF2 is, and why they should be using it to derive an encryption key is a task in and of itself. Enough of my soapbox. I will review this spec in more detail and give more constructive thoughts in the future. Thanks to @DarthNull and @tqbf for rousing me enough to write this post. WebCrypto has been on my mind, I know it will be creeping into our application work for years to come. Let this blog post serve as a point of reference for when we start seeing real apps using WebCrypto.

Both comments and trackbacks are currently closed.

3 Comments

  1. poulpitablog
    Posted September 24, 2012 at 5:39 am | Permalink

    Good to hear feedbacks on the webcrypto. As chair of Web Crypto WG, I will transmit your complains and compliment to the group :)
    Regards,
    Virginie Galindo

  2. ddahl
    Posted September 24, 2012 at 10:09 am | Permalink

    Thanks for pointing out @tqbf’s misinformational twitter comment on DRM. Luckily my responses (to that tweet) clear up the fact that DRM is not part of this spec, and Netflix’s use is also not DRM. Why don’t you read up a bit before pushing disinfo?

  3. bitexploder
    Posted September 24, 2012 at 10:52 am | Permalink

    Was just a bit of hyperbole on my part. I know DRM isn’t a part of the spec. Rants are no fun if they aren’t at least a little provocative.

    I will give some serious comments to the W3C group mailing list for WebCrypto to atone for this blog post, since it was less than constructive :)

image

This site is protected with Urban Giraffe's plugin 'HTML Purified' and Edward Z. Yang's Powered by HTML Purifier. 24681 items have been purified.