We are organizing another workshop on Internet of Things related matters. This time we will talk about the importance of software / firmware updates.
We are seeking input on this topic via the workshop. The workshop webpage also provides examples for topics, such as:
Protocol mechanisms for distributing software updates: What protocols mechanisms are available for distributing firmware updates? Do these protocols meet the needs?
What security mechanisms should be used for protecting software updates? What is the experience with those?
What meta-data about software / firmware packages should be provided? Is there a best current practice?
What are the implications of operating system and hardware design on the software update mechanisms? Are there new requirements that need to be taken into account with the increasing deployment of microcontrollers? Do high-level languages on these microntrollers change the way we will do software updates in the future?
How are software updates different on devices that provide hardware security (such as Trusted Execution Environments)? Can we make software updates on these devices easier for developers?
What are the privacy implications of software update mechanisms?
What are the implications of device ownership and control for software update?
We are looking for input on state-of-the-art techniques as well as requirements and ideas for future work.
With your contributions this will become an interesting workshop. Please submit your position paper by 20th May 2016 and we will see each other in Dublin on the 13th and 14th of June, 2016.
More information about the event can be found on the workshop page.
With this workshop we particularly encourage researchers and other security experts to analyse OAuth and OAuth extensions and to report their findings at this workshop. Please note the position paper deadline, which is May 21st.
In terms of the scope for the workshop we are seeking security papers related to OAuth, OpenID Connect, and other technologies using OAuth under the hood. Papers on technologies that are used in OAuth, such as JOSE, or impact the security of OAuth, such as Web technology, are also welcome.
We are looking forward to your contributions and to the discussions at the workshop! Feel free to contact us if there are questions.
In time for the data privacy day the FIDO Privacy & Public Policy working group released their FIDO Privacy whitepaper. This new whitepaper is targeted at regulators, data protection authorities, and “policy makers”. Of course, everyone with interest in privacy is also welcome to take a look at it. Due to the primary audience it includes a high-level summary of the FIDO protocols and the value proposition of the FIDO technology.
In the main part of the whitepaper we compare the European privacy principles (as outlined in Directive 95/46/EC) with the functionality provided by FIDO. The FIDO privacy principles on which the FIDO specifications are built are relevant to this description. To avoid a European-bias we also compare the Identity Ecosystem Steering Group (IDESG) privacy requirements with the FIDO privacy principles.
The description should help to gain a better understanding of how FIDO meets current regulatory mandates.
Today’s Internet of Things deployments are not known for their great interoperability. Typically, devices are only able to speak to one specific gateway, app downloaded from the device vendor, or to a single cloud provider. Getting devices from different vendors to talk to each other is challenging.
The reason for this situation is not necessarily a lack of standards; in fact there are various ways organizations and vendors are trying to approach the problem but the different solutions have pros & cons. Everyone seems to have their own story on how things be done. While many of these solution approaches are documented and published in specifications there are just too many of them. Are the requirements and use cases so different or we are just constantly re-inventing the wheel (without knowing the state-of-the-art)?
The Internet Architecture Board (IAB) is organizing a workshop that aims to shed some light on this topic in an attempt to find out whether there is interest to improve the situation. You need to submit a position paper to attend the workshop. We will review the position papers and then invite authors to attend the workshop (since the space is limited).
There is deadline for submitting a position paper, which is next Monday (February 22nd, 2016).
We received various questions about the workshop and I thought I should summarize some of them.
Q: Can we move the date? A: Unfortunately not. We know that there are conflicts when you organize these types of workshops since there are so many events going on at the same time. There are also events adjacent to this workshop, such as the Thing-to-Thing Research Group meets the two days before the workshop and the Bluetooth SIG has their meetings already right before the workshop starts.
Q: What do you expect as an outcome? A: Due to the position paper requirement we expect organizations, companies and individuals to submit write-ups that describe the current state of the art, as well as their ideas about where the work should be going. Having a good understanding of the state-of-the-art and an insight into the design requirements is important. At the workshop itself we will have lots of discussions and those will be captured in a workshop report. Of course we hope to all gain new insight in where we should be moving with the work on data and information models. Maybe there is some chance to harmonize the work across organizations to ensure better interoperability for all. Finally, the face-to-face meeting will give experts the possibility to connect with others. From past experience we can say that this will lead to more efficient communication across organizations.
Q: Is there a possibility for remote participation? A: Unfortunately, we will not offer remote participation. We have tried it in other workshops in the past and it just does not work. It is painful for those sitting on the remote end and it negatively impacts the discussions for the participants in the room. The socializing opportunities, which are an important part of such a workshop, are also lost.
Q: Will there be presentations? A: Yes, there will be presentations. However, those are different than in academic workshops. We are not interested in presentations that repeat the content of position papers. In fact we assume everyone has read he position papers before arriving at the workshop. The purpose of the workshop is to have discussions. A minimum number of presentations will be given to get the scope set and the discussions going. We want to have discussions on the aspects that have been identified as challenges from the position papers.
Q: How should the position paper look like? A: I have created a blog post about this topic some time ago (in context of another workshop). You may want to take a look at my short write-up. The workshop webpage also provides some questions for you to think about.
During the second week of November 2015 ARM TechCon took place in Santa Clara/California. The event is packed with presentations (from ARM and from partners) and new technology gets announced, such as the TrustZone for v8-M architecture. TrustZone for v8-M brings TrustZone functionality, which was previously available only to Cortex A class devices, to Cortex M class devices. Needless to say that this will lead to a huge security improvement.
In addition to all the exciting keynotes, tech talks, and tutorials Samuel Erdtman and I presented a demo that utilized OAuth 2.0 for Internet of Things devices. Our architecture is simple to describe and is shown in the figure below. We used an OAuth 2.0 authorization server enhanced with the latest proof-of-possession key functionality (as developed in the IETF OAuth working group). This authorization server issued access tokens after a successful login of the user (and assuming it had been authorized for this particular door lock). The access token was then stored on an Android-based smart phone app, which used Bluetooth Smart to communicate with the door lock. The door lock is a product sold by Nexus Technology and has been enhanced with the Bluetooth Smart radio offered by a Nordic board. For the communication over Bluetooth Smart a custom service and profile was defined, as it is common with many Bluetooth Smart-enabled devices. To protect the against attacks, the Android app utilized the symmetric key obtained from the authorization server and constructed a request using that key. In order for the door lock to verify the request it had to process and verify the received access token (which was in the JSON Web Token (JWT) format), extracted the encrypted symmetric key, and utilized that symmetric key to verify the request. Note that we had indeed used the JSON-encoding instead of the more efficient CBOR/COSE encoding developed in the IETF COSE working group due to availability of code for the JWT functionality. Despite the size of the access token (in comparison to the MTU size of the Bluetooth Smart radio) the transmission was so fact that it was not recognizable by a human. While the Nordic board was only using a Cortex M0+ it had no problems with the symmetric key operations.
To offer more details we also produced a slide deck that explained the relevant technologies in more detail.
We are planning to release our source code so that others can use the implementation as a basis for their prototypes. We are currently working on a CBOR/COSE-based version (thereby replacing the JSON-based encoding of the access token) and we would also like to see how a version using public key cryptography would perform.
OAuth 2.0 helped us to solve a common problem in the Internet of Things environment, namely authorization and access control, using an already standardized protocol framework.
Here are some pictures from the mbed booth where we showed our demo to interested parties.
The idea of my presentation at the Dallas IETF meeting was to get others to enhance the performance investigations to gain a better idea of what can be expected when using state-of-the-art crypto in IETF protocols as part of their IoT platform. The results could be summarized in an IETF draft, such as in the IETF TLS minimal draft of the LWIG group.
It turns out to be difficult to find someone who is interested in doing some performance analysis.
Here is what I believe we need:
Verification of the existing results.
More data from other crypto libraries (or even DTLS/TLS stacks).
Tests run on other hardware platforms (such as the Cortex M7).
Tests beyond performance, such as RAM usage, flash size, etc.
Tests that focus on other algorithms.
If you are interested in this topic and would like to contribute to the work please drop me an email (Hannes.Tschofenig AT arm.com) or via Skype (HannesTschofenig). I am also happy to take a look at prior work you did.
I am convinced it is useful for many engineers and researchers to know how fast the currently available algorithms are on modern IoT hardware.