Non-violent security talk for small and medium business @ BlendWebMix

In december, I was in a web conference, named #BlendWebMix, which gathers all kind of actors of the web economy, from investors to tech, including designers, influencers, politics, startupers, … Very diverse type of talks were given, 80, and 1800 people attended the event. I was selected to give a very short presentation on privacy and security. My challenge was : convincing a broad audience that the privacy was something each of us, as workers, should take action for, in 13 minutes. Here is the core of my message.

I am fed up with the usual talk in security which says ‘provide privacy by implementing some security or you will burn in the hell of bad reputation companies, together with Madison, Target, Yahoo, and potentially bankrupts”. You know, that Fear Uncertainty and Doubt (FUD). I tried another angle. I tried the non-violent path. And I believe there are at least two good reasons why people should give a chance (and budget and effort) to the privacy.


The first reason can be found on the optimistic side of the life. The good reputation. I have the feeling that in this digital storm of hacks, global attacks, social media bashing, the companies taking action to preserve the privacy of the users are playing a good game. And the user may know. And the user may appreciate it. And it may be a competitive advantage to invest and get rewarded for it.


The second reason is the data protection, as defined by the european comission. There is a new directive that mandates every company to allow its user to keep an eye on their data. It is the result of long discussions related to the value of the citizen privacy in our digital world. That regulation will be applicable in May 2018, to all European companies or all non-european companies handling some European citizen data. Well, yes, 2018 is after tomorrow. Which gives you only tomorrow to ramp up in good practices and get ready. The threat; if you are not compliant with the regulation, will directly touch your wallet, as fees could go up to 4% of your benefits, as a company. Universities and public services are also submitted to this regulation.

What does this regulation say ? It says that users will have to explicitly opt-in for registering their data, they will be able to control what you are doing with the data, they will have the right to modify and delete their data. In addition the data portability will have to be provided. Finally, users will have to be informed about any breach related to their data. Data in this context, means any piece of information which characterized the user, name, address, but also geo-localisation, social media activity, any digital evidence left by the user that you are collecting.

Who is submitted to this regulation ? Any company which collects, processes, transmits, stores the data. This means, you, but also anyone touching the data closely or by far. For example, the monetization partners (ads), or your cloud providers.  Now you see what could be the impact !

Duing the talk, I started a new technic for getting the audience sensitive to the message. I asked them to pause a second, to close their eyes, to breathe, and think about one of their user. Lea, 30 years old, digital, agile, conscious citizen, caring about her privacy. I asked the audience to answer in the secret of their mind and heart, eyes still closed, the following questions : do you know what are the data from Lea that you are taking in your super-super application or service ? Do you know where are Lea’s data stored ? When was the last time you had a conversation about privacy and security at work ? I mean, not on Twitter, being scandalized by the global surveillance of the states, but wondering, in your own framework. Some of the people in the audience smiled, and I felt some of the questions touched of them. What about you ?.

Targeting to convince the audience in a smooth way to take action for the privacy of their users. I reminded that it was important for them to identify the data, understand their life cycle in their own service life cycle, define some weak points (aka, any entry point, transfert, storage…) and protect those points. The thing is that of you are a small company, you may not know where to start. My key message was. Well. Start with pragmatic stuff.

First. Talk about security, create conversation around it. For example. Make a 2 hours meeting with the project manager or whoever in the company coded the solution, with a global view. And together make a status of the different security measures done up to know. Make an accurate status.

Second. Look for security champion(s) in your team. Basically the one(s) who had a security training at school or who had the chance to work on a security sensitive project in the past and may share with others.

Third. Write a process. It could be a paper sheet on the cafeteria reminding, i) before you ship a new feature, ask John (the security champion) to have a code review, ii) before you sign a deal with a company, check its track record in security, …. Or it could be a professional methodology for bigger companies. Well, the objective is just to make sure that the question of the security is handled in the product life cycle, at company scale, and taken into account in the delays and deals. This relates to create a security company culture.

Fourth. Engage conversation with your partners, providers, ask them the basic question on their security investment. They might be able to prove that they actually take care of it. With certification, or being able to tell you a nice story about their effort in that matter. Just like any company should be prepared to.

Fifth. Crash test your product. Some bug bounties platform are now existing. You can submit your product, it will be attacked by some hackers, and if some security vulnerabilities are found, you will be informed. The next level or complementary action could be to perform an audit of your code, or have actual security certification (but I guess that if you are on a market where security certification scheme exists, you might already be a security aware company).

Sixth. Have a monitoring of the security news. Read some newspapers specialize din sec, or some forum alerting on vulnerabilities. It would be a pity if your service bim-bam-boum were based on a framework which has been seriously hacked, and that you are not aware of.

In the end. Six possible concrete actions. To be rolled out by any non-expert security. I asked again the audience to close their eyes. And to pick in that list one action, just one action. And promise, in the secret of their mind to do it, Monday morning, when coming back in the office.Hoping next Monday some SMB will enter the way of improving privacy of their services….

Note : all picture copyrighted Garry Winogrand

Some news on the Trusted Execution Environment side…



Few time ago I wrote about the Trusted Execution Environment (TEE), and how promising it was. Few months ago, I mentionned the arrival of Trusty TEE in Android, an API allowing mobile application to interact with TEE based services. One can still wonder in 2016, where is that technology positioned.

A reminder about what is TEE. Well, it is always an isolated environment, shipped into smart phones, offering a way to deploy some code that will be securely stored and executed. It could support any mobile application that may require some sensitive operations and a trusted user interface, to insure what you see is what you sign.

But the major question when we come to nice technology is : “yeap, your stuff sounds cool, but, who on earth is using it ?”.

Well. Let’s see the facts. On the GlobalPlatform website, you can find 8 products that did success in the functional official certification. You can check this yourself here. Among the certified vendors, one can note Samsung.

And what does the silicon valley say about it ? A recent event allowed to have an overview of the market. It was the TEE Seminar that happened in October in Santa Clara. This is a regular seminar which is gathering the usual suspects of the TEE eco-system. Speakers include ARM, Visa, Trustonic (one of the well known TEE provider, a gemalto owned company), FIDO Alliance, Linaro (which offers an open source version of a TEE, named OP TEE), Ericsson, Verimatrix (guys in the game of the content distribution and IP TV), plus gemalto (my company) and G&D (one of my company competitors). The key topics of the TEE this year was Internet of Things. While the TEE technology seems to be distilled in the smartphone market via official products (see Samsung statement, Android Trusty TEE API and Secure Enclave [PDF] in iOS), the next wave ready to take benefit of it is about Internet of Things.

Any diverging creative geeks interested ? In the same October month, there was an interesting event which happened also in the silicon valley. A TEE hackathon #BuildWithTEE, dedicated to get benefit of the technology. It was organized by BeMyApp and GlobalPlatform. It happened that 100 people joined the hackathon over the week end. The pitch exciting moment was made of 22 smart ideas, 12 went until the end of the sunday and 3 winners shared 10 000 US dollars. The material provided to participants was a Linaro Open TEE loaded in a Raspberry Pi 3, and all they had to do was to play with Linux and impelment thier idea, with the objective to use key asset of the TEE, aka the security, on a client or a server side. Ideas that won were about monitoring door lockers when renting your house, deploying a privacy respectful tracking system, a centralized password management server. The IoT use cases were the major ones that the creative geeks wanted to explore.

So, to conclude, the TEE is a technology alive and kicking and will definitely support nice innovation in the field of all-and-everything-connected !

Note : Picture from




Tadaaa, Trusty débarque dans vos téléphones…


TL;DR. Trusty débarque dans vos téléphones, c’est un framework d’execution sécurisé, c’est cool, vos données ou les opérations sensibles de vos appli mobiles en bénéficieront. Et je vous explique ici comment, avec des mots simples – pour les gens qui ne sont pas des geeks de la sécu.

Votre mobile et la sécurité (mise en jambe du sujet). Les téléphones mobiles accueillent de plus en plus de données sensibles, relatives à notre vie personnelle, sociale et professionnelle. Si l’on a longtemps considéré que les attaques les plus courantes et coûteuses se passaient sur des systèmes informatiques centralisés, tels que des serveurs ou des systèmes IT, force est de constater que l’attention se porte maintenant, aussi, sur les téléphones mobiles. Des applications chargées sur un téléphone peuvent embarquer du code silencieux et effectuer quelques opérations inappropriées sans l’accord de l’utilisateur. La plupart des applications officielles, disponibles sur les portails d’application populaires, subissent une vérification de code. Mais il se peut que le code d’une application malveillante exploite des vulnérabilités non-encore déclarées du téléphone. Bref. Ce renforcement des attaques logicielles sur les environnements embarqués, en plus grand nombre et plus pointues a forcé les concepteurs des environnements d’exécution, tels que Apple, Google, Microsoft à renforcer encore les outils pour protéger leurs produits des attaques logicielles. Ce sont ces outils que nous vous proposons de passer en revue dans cet article.

La sécurité intrinsèque des mobiles (pour ceux qui avaient un doute). Les environnements d’exécution comportent des mécanismes qui permettent de les protéger d’un chargement trop facile d’application malicieuse. Les applications officielles sont en général signées par le fournisseur de service et/ou par fabriquant de téléphone, cette signature inclut la vérification des permissions de l’application, à savoir les librairies auxquelles cette application pourra accéder pendant son exécution. Il arrive aussi fréquemment que avant même que l’OS du téléphone boote, l’OS vérifie la légitimité de chacun de ses constituants, driver de périphérique, middleware, librairie applicative. C’est le principe du secure boot.

Les fonctions de sécurité applicative. On trouve également dans les environnements iOS, android, WindowsPhone et BlackBerry OS des fonctions, mises à disposition des développeurs d’applications, qui leur permettent de renforcer leur application. On trouve ainsi dans la dernière version de android Marshmallow, des packages tels que android.hardware.fingerprint pour gérer les empreintes digitales, pour générer des clés et effectuer des opérations cryptographiques. Il s’agit donc de mettre à disposition des développeurs des outils permettant de construire un modèle de sécurité plus robuste au sein même de leurs applications. On pourra donc rajouter une authentification de l’utilisateur par la vérification d’une empreinte digitale et la transmission de contenu entre le serveur et le client, chiffré ou signé pour en assurer la confidentialité ou l’intégrité (ou pourquoi pas les deux).

Le Trusted Execution Environement (nous y voilà). Les applications mobiles, intégrant les barrières de sécurité traditionnelles peuvent être soumises à des attaques de logiciel malveillants, résidant dans le téléphone, ou à proximité. Heureusement, l’art de sécuriser les environnements embarqués et ouverts, comme les téléphones, évolue et s’adapte. Ainsi, une nouvelle sorte de technologie a fait discrètement son apparition dans la planète mobile. Il s’agit du Trusted Execution Environment (environnement d’exécution de confiance, ou TEE). Penchons-nous quelques instants sur la définition de cette technologie. Quels en sont les mérites et les spécificités ? Le TEE est une technologie qui permet de garantir qu’un code d’application soit exécuté de manière sécurisé. Plus précisément, le TEE garantit que le code et les données d’une application ne soient pas modifiables ou lisibles par une application malveillante. Ainsi, l’intégrité et la confidentialité seront respectées pour une application, stockée dans le TEE. Cette technologie est définie par un organisme de normalisation nommé GlobalPlatform. Cette organisation regroupe des entreprises et industries provenant d’horizons différents, du fabriquant de composant pour téléphone, aux assembleurs de téléphone, en passant par les fournisseurs d’application bancaire ou les opérateurs téléphoniques. Les normes techniques du TEE décrivent donc les états possibles d’une application stockée dedans, le comportement en cas de détection de problème, les différentes librairies mises à disposition pour développer des applications. GlobalPlatform définit également des tests fonctionnels, permettant de démontrer une conformité fonctionnelle. Il existe également une méthodologie pour certifier la robustesse sécuritaire des produits embarquant cette technologie. Bref, le TEE est donc un objet technologique normé et certifiable.

Le TEE dans les téléphones, un mythe ? Non. Il a fait une discrète apparition dans les environnements de téléphone depuis quelques années, pour des fonctions internes au téléphone. Ainsi iOS mentionnait depuis quelques temps déjà une technologie appelée Secure Enclave, dont les vertus ressemblaient au TEE. Samsung indiquait que sa gamme de produit Knock dédiée dans un premier temps aux applications de production ou de gestion à distance de flotte de téléphone, reposait sur une technologie de type TEE. Récemment, c’est la plateforme android qui a clarifié l’usage de cette technologie. Ainsi, au début de l’année 2016, l’environnement android marshmallow met à disposition des développeurs un accès à la technologie TEE. Cette fonctionnalité est appelée Trusty TEE. Alors, en quoi consiste cette technologie ?

Trusty TEE, qu’est ce que c’est ? Tusty TEE, apparu dans Android 6.0  est une couche logicielle offrant les services d’un TEE. Trusty est composé de trois éléments : (1) un environnement d’exécution appelé le Trusty OS, (2) des librairies internes permettant d’accéder depuis le Trusty OS aux ressources linux, de manière sécurisée et de développer ainsi des applications sécurisées, et (3) une librairie permettant depuis l’environnement dit normal, d’accéder aux applications hébergées dans le Trusty OS. Il s’agit donc d’un environnement séparé du reste du téléphone, qui abritera des applications, dites sécurisées, pouvant être accédées par  des applications du monde normal, les traditionnelles applications android.

Quels sont les cas d’usage ? En théorie, un environnement d’exécution, privilégié, protégé contre les attaques logicielles comme l’est le TEE est très attractif pour protéger des applications sensibles. Plus exactement, puisque tout ne peut pas être exécuté dans un TEE, faute de ressource, on privilégiera d’utiliser le TEE pour l’exécution de fonctions sensibles. Par exemple, une comparaison de secret, une opération cryptographique comme la génération d’une signature, le stockage de secret, … La documentation d’android fournit une liste d’exemples pertinents, que sont les applications bancaires, les applications d’authentification, de DRM (oui, pardon..) …

Comment ça marche ? En pratique, pour le moment Trusty ne permet pas le développeur lambda de charger des applications sécurisées. Ceci reste le privilège du fabriquant de téléphone, au moment où il assemble les composants et intègre son code. Ainsi on pourra imaginer des applications permettant de gérer les empreintes digitales (capture, stockage et vérification) ou des applications bancaires pré-chargées. Pour utiliser des services sécurisés par l’environnement Trusty, il faut que chaque application soit déjà chargée dans l’environnement Trusty. Une fois chargée, l’application déclare les services qu’elle offre, grâce à une déclaration de nom (sous forme de domaine inversé, par exemple « com.mabanque.payment». Ce service est alors mis à disposition des applications dites normales, tournant sur l’environnement normal, dit non sécurisé.

Comment utiliser les services offerts dans Trusty (sinon, vous pouvez aussi lire la doc). Il existe une API Client et une API Serveur, qui permettent de mettre en relation une application sécurisée avec une application du monde dit non-sécurisé. A noter qu’il est également possible pour une application sécurisée de mettre ses services à disposition d’une autre application sécurisée. Voici en résumé comment tout cela se passe. Du côté de l’API Serveur, on déclare les ports grâce à port_create(), et on écoute l’arrivée d’événements grâce à une fonction wait(). Du côté de l’API Client, on ouvre une connexion avec un port connu par le biais de la méthode connect(), on se voit attribué un numéro de canal (dit channel). Une fois la connexion acceptée par l’application sécurisée offrant le fameux service, les applications peuvent échanger des messages en utilisant l’API Messenger pour transférer ses données, grâce aux fonctions send_msg() et get_msg().  Il n’existe pas de formatage particulier attendu pour le transfert de ces données puisque elles seront spécifiques aux applications. Néanmoins, au moment de l’ouverture du port et du chanel, on pourra spécifier si on souhaite une communication avec plusieurs buffers, et/ou de manière asynchrone.

En conclusion. La technologie permettant d’exécuter des morceaux de code de manière sécurisée, garantissant confidentialité et intégrité est en expansion. Preuve en est puisqu’elle se retrouve utilisable par des développeurs d’applications mobiles. On attend maintenant avec impatience les premiers services que les fabricants de téléphone mettront à disposition dans cet environnement Trusty.

Quelques références importantes. Oui.

Normes de TEE définies à GlobalPlatform :

Documentation Trusty

Note :

Picture by “Un savoisien à Paris” (


W3C : about security activities (gossips, new work and strategy)

This post is the third one, reporting about W3C TPAC activities. Previous ones were related to advisory board discussion and general technical topic. That one focus on my fav topic, security.

People following me know I am a promoter of security in W3C. And having done that in the last 4 years, I must confess I had some good surprise during last W3C TPAC week (which is the yearly big W3C party). Here is what I collected, going into official and unofficial meeting, coffee breaks and bars…

When Vint Cerf, Jun Murai, and Tim Berners Lee advocate for security. W3C TPAC day started with a 3 stars raw on stage, exchanging with W3C CEO Jeff Jaffe. (Note for the youngest ones, Vint Cerf invented the internet and is working for Google, Jun Murai has been contributing on that eco-system, being one of the most powerful japanese representative in the internet, Tim Berners Lee, is Tim…). Reading the minutes of that conversation, one could realize that security was at the heart of the exchanges. About making security in everything, about security being transparent, about strong authentication, about making the web a trusted place… While those gentlemen did not draw the technical solutions on any white board, but rather exchanged on such needed effort, this gave an indication about their next challenge for the web.

W3C security strategy is here. In order to answer to W3C members request about having a security strategy, the security strategic plan for W3C has been issued. The Technology and Society domain considers two aspects for securing the open web platform : the user security (including web crypto API, web authentication and HTTPS migration), the web app security (including CSP, sandboxing and HTTPS, again). Another track is about making sure that the development of the open web platform takes care about the security, and this implies having security reviews, handling with care the migration to HTTPS, and liaising with the rest of the world thanks to liaison and wide communication. See more about that security strategic plan here :

The migration towards an HTTPS world. A very interesting session was held during TPAC about trying to find the best path to make the web an HTTPS place. HTTPS is good says the W3C Technical Architecture Group. We all know that (well, kind of). But the path from HTTP to HTTPS may raise some serious challenges that Brad Hill explained very well in that document. The problem is about mixed content. How to make sure, once your website is mandating HTTPS, to still get content from website only running in HTTP ? What security measure should be taken when this situation happens ? Would not that be the weakest link that would kill the entire security promise… No conclusion was drawn from that discussion, but some solutions were excluding (for instance a 2 steps migration path that would be highly insecure for all the web).

W3C seeks for a security geek. Based on that ambitious plan, W3C has opened a position for strengthening the team, on security aspects. For more information, you should contact wendy from W3C (wseltzer at w3 dot org).

Web App Sec business as usual. Working hard and quietly, the Web App Sec is rolling out its plan. I have already mentioned the main topics being dealt in this Working Group, made of best security experts of major browser vendors. One may note that little by little, Web App Sec is providing developers with a tool box allowing to check integrity of a ressource (SRI), filter or log access to external ressources (CSP), access to specific API only in secure context (privileged Context) … Nevertheless, some recent activities are worth (re)mentioning, completing this intention :

  • COWL : is about Confinement with Origin Web Labels. In other words, this is a mean to lable some code and execute it carefully (because you dont trust it, because you want to allocate him less permission…). That work is in first public working draft (early stage of a spec) and is available here :
  • Clear site data : is about allowing web app to kindly ask browsers to delete data related to itself. The spec is available here :
  • Upgrade unsecured data : is about allowing web app dev to instruct browser to upgrade all interactions between client and server on HTTPS. the spec is available here :

You can have a look at the complete status of the Working Group deliverables edited by its co-chair Brad Hill.

Last but not Least. Some new work is being introduced in W3C.

Web Authentication. Is about allowing strong authentication from a web app. That working group will certainly be the place holder for W3C receiving FIDO Alliance specifications which are defining an API for authentication, attestation of a authentication device and signature. The draft charter is under construction here

Hardware Security. Is about allowing web app to access secure services made available thanks to hardware based token (like secure chips, smart card, trusted execution environement). the ones knowing my everydays job will definitely recognize the usual technology I am playing with, and may understand the reason why I have offered to chair that working group, together with David Rogers, a mobile security expert. The draft charter is available here :

Those two new pieces in W3C still have to go through the W3C member review before being actually up and running. Again, here, I will keep you informed.

Paris Web : de la sécu et de la qualité


L’été bat son plein. Cigales et soleil (enfin, pour moi). Je me penche sur le programme Paris-Web, la conf du web programmée en Octobre (oui, déjà, je sais, certains disent que je suis très prévoyante), et joie, bonheur, extase : de la sécu, il y en aura à gogo chez Paris Web cette année. Rendez-vous compte, pas moins de 6 interventions relatives au sujet.

– Votre cauchemar ressemble peut-être à une invasion de script malicieux sur vos sites, Nicolas Hoffman vous racontera que CSP est un anti dote pour ce genre de situation embarrassante.

– Vous avez envie de rendre un peu plus robustes vos applications web ? Il existe des outils pour cela. Mathias Dugué partagera son retour d’expérience sur l’usage de ces outils obscurs de sécurité et de la Web Crypto API.

– Une bonne authentification est la garantie d’un service deployé sûrement. L’administration française l’a compris. Francois Petitit partagera son retour d’expérience sur le déploiement de FranceConnect, de OpenID, de l’OAuth2, du bonheur…

– Les bots sur le net générèrent du traffic, et vous embêtent probablement en tant que webmaster, François Hodierne vous expliquera comment gérer ce petit détail, et comment reconnaître les bons des mauvais robots.

La sécurité du web et des internets, c’est un sujet sérieux, que les organismes de standardization discutent, je viendrai vous raconter les avancées faites dans ces consortiums d’industriels au W3C, à l’IETF, et à FIDO.

– La sécurité, c’est aussi une question sous-jacente dans les enjeux de la liberté des usagers du web. Adrienne Charmet, de la Quadrature du Net, viendra plaider pour un engagement des acteurs du numériques en plénière d’ouverture..

On se croise donc à Paris-Web les 1/2/3 Octobre ! #bisous

The security question at Edge

Take 250 web developers, seat in front of them experts, and let them interact. This is EDGE conference. While being my first edge conference experience, I cross finger I will attend the next one. I went there to be part of a panel dedicated to security. And by having that lively and passionate debate, I have learned things, specially, how to move forward on security aspects on the web.

What was it about ? It was about HTTPS and certificate usage. The panelist were Yan (from Yahoo), Mike (from Google), Alex (from University of Michigan, Let’s Encrypt promoter), Patrick (from Financial Times) and all of us being moderated by Dan.

Yan setup the stage by reminding what are the attacks on the web (MITM, XSS, …) that HTTPS and CSP can help to solve. CSP is a way to control that only authorised resources are accessed (authorized means coming from a url you trust). At the same time Yan announced also a renaming of CSP into BATSHIELD to make it attractive, we hope you will enjoy it. Then came the origin question. HTTPS is a way for the browser to make sure that the service your are accessing is the one it pretends to be. And from there, we entered into the debate, here is a take away.

So what is it that we know about HTTPS ?

HTTPS allows point to point authentication and communication confidentiality, between the browser and the server. It helps to prove that Steve’s service is from Steve. HTTPS relies on public and private key management, which means key pairs, generated and certified by a certification authority (CA). In other words, CA will help blessing Steve’s key pair. CAs are recognized by browsers and this recognition relies on reputation. If a CA is reliable (aka known for doing Steve’s identity check properly and making sure to repudiate his certificate if he behaves badly on the internet) then browser will add it in its recommended CA. And all services associates with certificates and key pairs delivered by trustable CAs will be operated under HTTPS. Key pair generation and certificate issuance are a painful process for the web developers. In addition to migrate to HTTPS, they need to pay, few tenth of dollars and find a CA kind enough to have their certificate. In September, Let’s encrypt project is arriving It will make the certificate and key pair distribution automated, free and seamless. Thus it will reduce the barrier to entre the HTTPS world. The way this process will be reliable and automated is still to be discussed, but this initiative could be a serious enablers towards an HTTPS everywhere scenario.

And what is it that we don’t know ?

Does HTTPS really need to be end to end ? Some services may require some arrangement in the middle of the path, between the server serving the request and the browser. The kind of arrangement could be advertising loading, load balancing management, ….). If we were to open some non-HTTPS path in a HTTPS request, to favor the work on the intermediate elements, in charge of those arrangement, this would imply the risk to have middle box for monitoring also enabled. So on one hand there are some business interest to let some path HTTPS free, on the other hand, the breach opened here could favor pervasive monitoring… So one should ask if this is reasonable to only protect the last miles on the communication.

How should users be involved in the security cursor ? Users are warned today when a site is safe, with a green lock. It pushes him into a perception of security that may be over estimated. Some browser vendors would be in favor for waking up the user only if something is at risk. This opens the question to how far security should be visible to the user. It is the responsibility of the browser today to accept CAs and to operate HTTPS normally. Including an educated user could be good, but what if the user is not skilled enough and accept any CA ?

Does HTTPS make the entire web safe ? No. HTTPS is a mean to increase the security communication between a server and a browser. But it does not protect from (1) threat happening on the server side (what is server’s data are corrupted), (2) what is happening on the device side (what if some malicious application can explore and alter broser data), (3) the web developer private key protection (what is the service has his private key being compromised). So a complete answer to securing web business is also about answering those questions. But we dont know yet how to do that and have information about security context of the entire service.

What about restricting sensitive features of the web through HTTPS only connection ? This could become a possible way to increase user privacy and control. But some are claiming that this would force web developers and services to migrate to HTTPS for accessing specific features. Putting a higher technical barrier for deploying services (providing that certificates become free commons). Those last questions staid unanswered. Nevertheless this very good dialog with experienced web developers at #edgeconf allowed to hear pain points and fears from the audience. My take is a beginning of action plan to answer to those questions. Being involved in” problem solving by standard”, I would recommend that we create some fair places to discuss and solve the following questions :

  • HTTPS end to end best practices – including the middle box problem.
  • User involvement in security indication and management – including user experience concern and creating a standard for making the users indication clear
  • Guidelines and supporting tools for web developers to deploy HTTPS and endorse certificate usage (from whatever CA it comes from).

I guess that W3C and IETF may hear in the coming weeks about those suggestions about for keeping our web safe.   Note : extensive notes are available here by Orde Saunders

W3C master plan for making the web a trusted place

Long Board Paris by serge klk

Snowden has gone. Other privacy and or security stories happened. Some people might have forgotten but W3C does not and is still attempting to make the web more secure. Few pieces of technology reported here relates to that master plan.

W3C recommendation about Securing the Web is live.

That document named ‘Securing the Web’ is actually a finding from the stewards of the Web architecture, the W3C Technical Architecture Group, and deals with the usage of HTTPS. It basically says that it is preferable to actively use secure communication, to ease adoption of https:// and play with a trusted end-to-end TLS encryption on the Web (aka, do not use broken algorithms).

Web Crypto API is here (or almost).

The Web Crypto API has landed in several browsers, and it is under finalization. As soon as the testing activities will be completed and that two interoperable implementations will be evidenced, it will become an official W3C recommendation. In the meantime, you can still read Charles Engelke  blog post [1] and table [2] tracking which browser implements which algorithm for which usage.

Spoiler : “RSA-PKCS1-v1_5 for digital signatures, RSA-OAEP for public key encryption, AES-CBC and AES-GCM for symmetric encryption, HMAC, and SHA-1 and SHA-2 hash functions are pretty much universally supported”

New WebAppSec guys mission, chosen.

The ones designing the web app security model are not legion, you can meet them in the W3C Web Security Working Group. If you want to know what they are willing to work on, you can have a look at their recently rechartered mission. Menu is impressive  : garanteing web app silos, secure mashup, anti-clickjaking frames, user permission and HTTPS/HTTP juggling.

Security review will one day be natural.

There has been lots of discussions on the idea that W3C specification should actually go through a formal security revision. The main blocker from not implementing such a great idea is the lack of security experts, having enough time and money to perform an extensive and serious review. Mike West, from Google, started a security questionnaire that would help the editors and chairs of W3C groups to evaluate the sensitivity of the feature they are designing, and thus increasing awareness in the hole W3C community. The draft questionnaire is available here and anyone can contribute on the github project ! One should note that the W3C Privacy interest Group is also working on guidelines to help groups to reduce the fingerprint of the browser when designing their new features.

W3C TAG welcomed new security geeks.

Recent election in W3C Technical Architecture Group resulted in the addition of two skilled security members. Mark Nottingham from Akamai and Yan Zhu from Yahoo (yes, a girl in TAG, clap, clap, clap). This will definitely increase awareness of TAG on security best practices. Next challenge those two will face, is to clarify what are the types of resources in a browser that should only be accessed via a secure connection (aka Privileged Contexts).

All that good news will definitely favor the trust on the web.

And we should try to support it. As a reminder all W3C work is conducted in public and anyone is invited to bring their skills and share ideas. That is quite easy to do, as most of the working groups do have a public comment mailing list. Find the one you like and start contributing !



Note : picture by serge klk under CC BY-NC-ND 2.0

FIDO Alliance : an amazing standardization story

la piste aux etoile by abac077

As you know, my main job is to jump from one standardization body to another. In (my) history of meeting this kind of tribes, I have witnessed several birth and death of SDOs. I have gone to the traditionnal ETSI, the rich GSMA, the working hard GlobalPlatform, the always-been-here TCG, the fabulous W3C… None of them, from my view, had a development such as FIDO Alliance did. Seriously. Jumping from 4 founding folks (Lenovo, Validity, Paypal, NokNokLabs) to a list of 170 (paying) members in 2 years. This is amazing. For the ones who missed it, few facts and figures about FIDO Alliance.

FIDO Alliance primer goal is to design a solution for seamless authentication on the web, under user control. Born in 2013.  Worked under the water during one year to write spec, evangelize and recruit. Showed at MWC 2014 – different products , including a commercial deployment by Samsung and Paypal. Announced a Google launch named Secure Key in October 2014. Issued its first set of specifications in December 2014 (aka 500 pages of architecture, protocol, documentation, …) and may surprise us again during the MWC 2015. In the meantime, the Board increased to 22 members, to include major players such as (sorry long but impressive list worth sharing it here) Alibaba, ARM, Bank of America, Discover, Google, Mastercard, Visa, Microsoft, NXP, Qualcomm, RSA and Samsung. Those guys are the ones paying the most and directing the strategy.

Seriously. So much people around that specific problem. There must be something. One may argue that at the moment the co-existence of two different technologies (UAF and U2F for acronyms geeks) may reduce the value of FIDO Alliance to solve one single problem. Maybe. But it kickstarted the market, and it was required to have Google family joining the conversation, and thus having all the major actors around the table.

Nevertheless, such growth should have never happened without the following assets :

– a clear value proposition : hey, come on, let’s kill passwords ! (a real challenge in the security area)

– a strong marketing and business development team, backed with serious financial interests, being everywhere, in any single conference approaching the authentication topic.

– a continuous  positive and monitored communication, encouraging and valuing product or members PR.

– a clear governance : you pay, you decide, you pay less, you influence the technical stuff, you pay few, you listen and implement.

– good and committed technical folks to chair the working groups and edit the specs (folks like Brad Hill, Jeff Hodges, look at the names here).

– a pragmatic product functional compliance approach (aka interoperable test fest before thousands of tests being developed).

I’d say that FIDO Alliance may succeed or not (I wish it will), but the growth of that SDO is amazing and we should, first get inspiration from their good practices, and second, listen to FIDO Alliance announcement during this year, hoping those guys will talk loud.

Note : picture by abac077La piste aux étoiles” in CC BY-NC-SA 2.0

About the very simple question of identity, security and privacy in Web Payment

w3c web Payment_small.jpg

Again, about the W3C Web Payment Workshop in Paris. Two weeks ago, discussion went on the definition of payment, the notion of user experience, the architecture of back end systems and the end to end picture. The main objective for such workshop was to identify web related topics on which all parties (merchants, banks, payment schemes, regulating government, payment service processors, ….) would agree to get more standard. This will take time as I already mentionned in a previous post. The conversation was structured, but it happened that for each of the scheduled sessions, after one hour of talk, the questions related to identity, security was systematically raised. How can you garantee that the payee is the one he pretends to be ? How can you you garantee that the money is safely transferred, stored ?  As moderator of the Identity, Security and Privacy, I felt like my panel would be an interesting piece of the workshop.

Throwing the question ‘how can you garantee your system is secure ?’ is a little bit unfair.  Obviously, no one can garantee a system to be 100% secure (at a certain point of time, someone will break it), so you have to think about risk evaluation, tools to help implementing security, indicators to monitor trust… And this is what the poeple from the panel shared : good practices, feedbacks and valuable advices to build a common solution to bring with payment some notion of identity, security and privacy. Here is my take away from the discussions.

Identity, what is it ? With Louise from British Computer Science and Tim from Microsoft, we explored the notion of identity with two different perspective. Tim, involved in the e-commerce platform of Microsoft shared with the participants a notion of commerce identity, that would encompass our usual personal information, but also our friend, our relatives, our payment means, our interactions, our reputation. The idea suggested here was to build one identity, based on the principle of aggregating our identities and make it available to services providers via APIs. The direct consumers of this meta-identity could be banks, merchants, but also anti fraud banking system,  government, locally or international. Obviously the question of user control and privacy was raised. And this is where Louise made a great speech about the way identity, privacy, anonymity, traceability were major topics that companies, citizen and regulation should take care of. The rationale for this special care was the coming explosion of peer to peer financial transaction enabled by the web. This use case would multiply the needs to protect peers, regulates fraud and balance privacy aspects.

Identity, who should manage it ? Several participants gave a view on that notion of handling identity. Natasha Rooney, from GSMA mentioned in her  contribution that they had a program named GSMA Mobile Connect, which would allow service providers to use mobile network operators users database and trust the identify of those users. This offer completed with a strategy of direct billing on subscribers bills would position them as ideal identity providers in mobile commerce. Another view, Ripple Labs, the ones maintaining Ripple Network, mentioned that identity should be managed in a decentralized way. What does it mean ? Ripple Network is a network payment solution, which relies on a network of Ripple Gateways. Those gateways are disseminated all around the world, and this is where each user willing to transfer money should register, providing with email and banking details. Choosing a gateway suiting his constraints in terms of currency, transaction operation … Each Ripple Gateway implements the Ripple Transaction Protocol which allows to transfer money from any currency from one user to another, provided that this one owns a Ripple Wallet. In that case, identity is managed by registering to Gateways. The case of Facebook and Google managing the user’s identity was not directly discussed but raised on a regular basis. One could conclude that several identity provider profiles could be defined, from traditional kinda official (MNO) to decentralized email based (Ripple network).

Identity, how to convey it ? Lets say you are an identity provider. You need to offer services to consume your user’s identity to service providers. The next questions you would have to answer would be : which protocol should support exchange of identity related information? which piece of the identity should be shared ? how to make sure that the user agrees with sharing his identity ? Most of the presenters mentioned the recently published Open ID Connect as the technology that makes the job. First, it relies on the recent version of OAuth, an authorization protocol that Hannes Tschofenif, co-chair or IETF OAuth WG exposed to the audience. Hannes concluded saying that OAuth was a good enabler for identity scheme, provided that security recommendations were implemented and that proprietary plug-in were not killing the interoperable nature of it. Second, Open ID Connect includes an flexible authentication mechanism (how do you make sure the user authorizing access is the right user). Stefan from Ripple Labs confirmed, adding that Ripple Network was using it, allowing a good granularity in rights and flexibility in user authentication. Ripple made password and game with cryptography, but one could imagine to have the FIDO Alliance UAF technology used for such authentication.

Payment, identity and security, what promise ? About the actual enablers for security in web payment, we heard several voices promoting different types of perspectives. On the device side, Giri from Qualcom said that mobile payment security scheme could get benefit of user’s contextual information, combined with trusted enablers, listing technologies the web payment could benefit from : geolocalization, multiple factor authentication, hardware token and fingerprinting. On the protocol side, Hannes recalled the audience that state of the art in security as promoted in IETF should be implemented to avoid failure. There was a consensus on the fact that cryptography was a great enablers of trust and security (trusting someone could be translated as sharing a cryptography secret with him). This is what Harry Halpin from W3C promoted the recent Web Crypto API (that my readers all know went to Last Call last week). This API will allow developers to manage and use keys in their web applications. Last but not least, Gregory from Lyra Network among other good feedbacks for promoting a decentralized web traffic to increase trust, reminded that users were to be educated in order to have a better control on their identity data and data in general. He also highlighted the idea of building identity of users on multiple devices, including the ones belonging to the wearable IoT wave, feeding the *what you have* factor to authenticate users.

This session did not bring any direct conclusion on the complex problem of identity, security and privacy, but drove the audience on different perspectives. The excellent minutes and presentations from that session are available on . All the web community is now waiting for the W3C report on that workshop, which will sum up and prioritize the possible actions that could happen in W3C.


Web Security : a snapshot from W3C


For the past few months the web has been in the headlines for bad reasons (but also for good reasons such as its 25th anniversary). The bad side pointed out a regular basis concerns broken servers, denial of service attacks, leaking connected-apps, massive internet monitoring… Everyone’s wondering what are we doing so wrong? Well. First, people have to eat, so business does go on. But once given food, and this is the good news, people are talking about security problems. Realizing they must change something. Alone. Together. Against. But they must move. And organizations such as the W3C are fostering those discussions. People exchange views, make alliances, start thinking about solutions. After all, this is what standardization bodies like the W3C are made for. Find collective solutions, serve both business and social interests. Let me share with you few interesting evolutions:

* Strong web apps, strong internet

Prior to the last IETF meeting, the STRINT workshop took place, the tag line of which was ‘strengthening the internet against pervasive monitoring’. From both W3C and the IETF, attendees discussed how to bind the existing internet specs to make them stronger, but also discussed new features to think about, to avoid facing more governmental invasion in the internet flow. While waiting for the report, one can read the minutes.