Cool, we have won two awards at the same time, for the SwissInnovation Challenge: one for innovation, one for internationalization. Here our press release:

Oberon enables device manufacturers to add smart home support to their door locks, thermostats and window blinds, while maintaining the highest level of security standards. At an event of the Swiss chamber of commerce of Basel Land, Tag der Wirtschaft, Oberon was named a winner of the SwissInnovation Challenge in the presence of Swiss Finance Minister Ueli Maurer. Moreover, Oberon also won the special award for internationalization. In 2016, the SwissInnovation Challenge has been held for the second time by the University of Applied Sciences and Arts Northwestern Switzerland (FHNW).

In home automation, a high degree of security is essential. While advanced security standards are widely available for the Internet, this is not yet the case for home devices. Oberon has recognized this fact and has implemented the highly secure cryptographic algorithms that Apple mandates for smart home devices. Thanks to novel optimizations, run time and memory consumption was minimized, so that the Oberon software can even run on low-cost microcontrollers, as they are used in home devices. For example, the implementation easily fits on the Bluetooth chips of Nordic Semiconductor, where opening a secure connection takes less than the tenth of a second.

I've been relatively silent on this blog for a while, because we've been (and still are) heavily absorbed by our HomeKit business (see also this blog post or the separate site http://oberonhap.com). HomeKit was announced by Apple two years ago, at WWDC 2014. That we could enter this new ecosystem was a matter of serendipity, of being at the right place at the right time - made possible because of work we've done earlier for the Limmat gateway.

Currently, WWDC 2016 is taking place. On Monday, we've been (very...) pleasantly surprised to see our company logo on Apple's stage. During the keynote, no less. In front of 5000 developers and uncounted viewers of the live stream. HomeKit is a huge and complex ecosystem play, but is slowly switching into higher gear. Looks like our work is beginning to bear fruit.

We've just moved to a larger and even more centrally located office, near the Zürich main station. The address is now Neugasse 10, the postal code remains 8005.

In part one of this blog post I have indicated why secure remote firmware updates are important, and how a firmware update mechanism may be threatened. Let us look at some ways for mitigating such threats.

End-to-end security is an approach that addresses many of the threats shown in the first part (the arrows in the diagram). The idea is to encrypt data - in this case firmware updates - by the sender at the origin of the data, transmit the encrypted data over some channel to the receiver - in this case the gateway - and decrypt it there. Intermediate stations, e.g. proxies or servers of the Internet provider, only see encrypted data, never clear text.

Actually, encryption is only relevant for firmware updates if their code contains confidential data, e.g. intellectual property such as a unique sensor fusion algorithm for a medical device. Otherwise encryption, and thus confidentiality, is of secondary importance. It is more important that data can be signed by the sender in such a way that the receiver can check whether the data indeed comes from the correct sender (which is typically well-known, as IoT devices rarely need to be "promiscuous"), and whether the data has been transmitted without changes (authenticity and integrity).

When a machine, e.g. a printing machine, is connected to the Internet, this enables remote diagnostics and remote control. This in turn allows to react faster when a problem occurs, downtime can be reduced or even prevented completely thanks to predictive maintenance. A gateway is used to connect the machine to the Internet - and potentially misused by attackers to get access to the machine (visualized by the shark in the simple Internet of Things model shown below).

So security of the machine is clearly depending on how well security of the gateway is implemented, and therefore on the protocol stack of the gateway - e.g. see the Heartbleed vulnerability in the case of OpenSSL. There exist higher-quality implementations of TLS, but even in these products security holes are found from time to time, and thus they must be updated when fixes become available.

In this post, I'll not talk about Limmat, but about another ongoing project at our company Oberon microsystems. Unlike Limmat, this project has nothing to do with the Industrial Internet of Things, but with the Consumer Internet of Things. It has to do with Apple's attempt at cracking the home automation market.

About 15 years ago, a manager at a company that produces thermostats for commercial buildings told me that, according to market researchers, the take-off for the home automation market is predicted to happen in five years. And had been predicted to happen in five years, for many years. He wasn't optimistic that this would change anytime soon. Indeed, the expected explosive growth of the home automation market (beyond enthusiasts and makers) has remained five years in the future.

Today I gave a talk about the Limmat platform at the Embedded World trade fair, the largest of its kind. Below you can find the slides of my presentation.

If you would like more information, you can get the 10 page technical companion paper by subscribing to the Limmat mailing list on the Limmat home page.

Cuno Pfister, Oberon microsystems AG

Often, IoT devices are naturally used as servers. For example, the standard GATT REST API of the Bluetooth SIG treats a Bluetooth Smart gateway as an HTTP server (while being a Bluetooth Smart client "on the other side"). In many cases, it even makes sense to treat a device as both an HTTP server and client. For example, in our Limmat Beacon API a gateway device is an HTTP server for letting a subscriber register a Webhook, and a client for pushing beacon events to Web services.

This means that a gateway must not only be able to act as a client (i.e., opening "outgoing" connections to the other endpoint, sending requests, and receiving responses) but also as a server (i.e., accepting "incoming" connections from the other endpoint, receiving requests, sending responses).

In general, it is not possible to open a connection from anywhere on the Internet to a gateway via 3G, as firewalls of mobile network operators typically only allow outgoing connections from their networks (see figure below). Network address translation (NAT) adds further obstacles to the use of incoming connections. It is often possible to buy private access points, where the firewall rules are relaxed, but this can be expensive and a major hassle, in particular if you have to do it individually for several operators, in multiple countries.

While this is an artifact of how mobile operators work today, it seems unlikely to change anytime soon (even in spite of IPv6). Moreover, there are good arguments why low-end gateways in general should never open any incoming ports: handling incoming connection requests consumes memory and processor cycles, which makes such devices prone to denial-of-service-attacks. It is safer to only open outgoing ports and leave the handling of attacks to far more powerful servers, and to organizations that are able to detect and react to such attacks.

On today's Internet, HTTP is the most relevant  application layer protocol - as it is the foundation of the World-Wide Web, and therefore the basis of most of the Internet's economic value.

For the Internet of Things, there is an ongoing discussion about the possible need for other application-layer protocols. Typically, proposals for such protocols are all based on either UDP/IP or TCP/IP, the core network and transport layer protocols of the Internet. But let us first take a look at HTTP.

HTTP/1.1 is the protocol that allows browsers to request Web pages from a Web server, usually represented as HTML documents. This is the Web as we all know from direct experience.

Limmat is a gateway platform that allows you to bring your own gateway product to market faster and with less risk compared to designing it yourself from scratch. We have created a reference board design (Limmat V1.1) that can be used as is, and which is ready for RF certification. This is the board that we will make available to prospective licensees as part of our Limmat Evaluation Kit. It measures 100 mm by 50 mm, which makes it suitable for various off-the-shelf enclosures that use the Eurocard form factor. You can choose one of these products, or design a custom enclosure for the board.

In this blog post, I show you pictures of three different enclosures. The first is an off-the-shelf 105 x 80 x 30 mm aluminum Eurocard enclosure. The second is a custom variant of a similar enclosure, 105 x 50 x 24 mm. The third is a custom 3D-printed enclosure that we created for demonstration purposes.

The entire Oberon microsystems crew wishes you a merry Christmas and a Happy New Year!

Our Bluetooth Christmas tree, with lots of our BLE Advent Wreaths

Just in time for Christmas, a batch of second-generation Limmat eval boards was produced yesterday, and the boards have tested out just fine. Below some impressions:

We've experimented with a number of 3D-printed and off-the-shelf enclosures for our Limmat eval board. We've now selected an enclosure that we recommend for industrial applications as the default, unless there are specific requirements for something else. The back panel is custom-made, we just received a batch of these panels:

Of course, as Limmat is a reference design rather than an off-the-shelf product, you can select any other suitable enclosure and have us adapt the board layout accordingly.

The Limmat board is an Internet-connected Bluetooth Smart to Web gateway. This blog post is about a case study for a presence detection system. It is based on a project done by Oberon microsystems, Inc. for Lomali Solutions GmbH, a company developing a Web based CRM/ERP for SMEs. In this case, the system is used to manage cleaning personnel. Note that Oberon is also the company behind the Limmat board reference design.

Bluetooth Smart (or Low Energy) has been quickly adopted as the technology of choice for connecting accessories to apps, using the smartphone as a gateway to the Web. It's also now common to see Bluetooth Smart beacons in scenarios where someone entering the room with a smartphone can detect and use beacons mounted there, e.g. for in-house location.

Today we turn the scenario on its head. We will use a fixed Bluetooth Smart gateway, the Limmat board, detecting beacons entering or leaving the room. An application where such a setup might be preferred, is the presence detection of cleaners in an apartment.

Let's have a look at the status quo: cleaners go to an apartment, open the door with a key they got from their manager, start cleaning, and leave again right after finishing their work. They write down the start and end time or the number of hours spent cleaning each apartment. Sometimes a cleaner forgets to take notes. Others do it at home, off the head. This can result in too many or too few hours accounted for, which is bad for both the cleaners and their manager.

Hello, Cuno Pfister here. I’d like to ask you a small favor.

We're close to finalizing the design of our new Limmat hardware and firmware, for a highly customizable reference design for Bluetooth Smart to Internet gateways. Limmat will allow access from the Web to Bluetooth Smart sensors (e.g., tem- perature sensors), actuators (e.g., light bulbs), or beacons (e.g., iBeacons, or smartphones programmed as beacons). We have been working on this techno- logy since 2011 and are finally going to wrap it up.

Limmat can be usable for person or asset tracking, e.g. to detect smart crates entering or leaving a warehouse, for lighting control, for the monitoring of smart environments (from industrial plants to smart gardens), etc.

However, I need your help. Before we finalize everything, I would like to make sure we have covered all the right things for the initial release. This is where you come in. If you might have a use for such a "Smart Environment Gateway", please take a few minutes to answer my brief (!) survey.

Last week I gave a talk at the Wireless Congress in Munich, titled "Bluetooth Low Energy for the Last 30 Meters of the Internet of Things". You can find the com- plete companion paper here:

Cuno Pfister, Oberon microsystems AG

The Internet of Things can be a daunting topic. It involves countless protocols, and allows for many architecture variants. As a result, it is difficult to find a simple, yet still useful mental model for discussing the topic, without glossing over important aspects. In particular, I want to be able to discuss questions like "which protocols are suited for the IoT", "what services should an IoT cloud platform provide", "do we need CoAP support in a browser" and similar questions in a meaningful way. Here is my attempt at such a model. Feel free to comment!

In my Internet of Things reference model, let's call it the IoT Triangle, I distinguish between three domains where different technical requirements apply, different technologies are established, and different quality attributes are relevant. They are: Cloud Services, Smart Screens, and Smart Objects. I'll briefly discuss each of these domains, and then the communication links between these domains. The pink background represents the open Internet with botnets, NSA and other threats, while the grey bubbles represent more controlled "edge networks".

Hello everyone

This is my first blog post on our Limmat site, where I will blog mostly on Bluetooth Low Energy, the Web of Things, and how to bring them together. Occasionally I will look at other protocols that may be relevant to the Internet of Things, and at Internet of Things architecture issues.

I'll start with a quick report on last week's Bluetooth Europe, the first and hopefully not the last European Bluetooth event. It has taken place on September 16 and 17 in Amsterdam. It was fully focused on Bluetooth Low Energy, although everyone went to great lengths to avoid this name, in favor of the Bluetooth Smart label. Google trend tells me that Bluetooth Smart is winning out, but I guess like most other techies, I feel that I can continue using the old name for a while, and in particular the BLE abbreviation. BS as abbreviation for Bluetooth Smart? No way!

Over the last two years, BLE has become highly popular in particular in the Wearables space: fitness trackers, smart watches, etc. Its growth has surpassed that of classic Bluetooth with audio streaming as its key use case, although last year's growth of BT classic of about 20% is nothing to sneeze at either. A market analyst expects that already in 2015, more BT chips that support BLE (single mode or dual mode) will be sold than pure classic BT chips.