Given the inherent sensitivity of any personal medical data, access to data in a device such as Grindcare must be strictly controlled. Medotech decided to use Nabto\u2019s micro-server software, uNabto. It embedded a uNabto web server in the Grindcare device, and a secure plug-in program was installed in the dentist\u2019s browser from which to access readings.<\/p>\n
The system requires no specific configuration by the patient. The device powers up and can be controlled once Internet access is available. All communication is encrypted and both peers are cryptographically authenticated. As well as controlling the patient\u2019s Grindcare device from an office PC, the dentist can also access the system over a smart phone using a dedicated Nabto \u2018app\u2019.<\/span><\/p>\n MCU developers often face remote-access challenges. The main problem typically lies in providing\u00a0 ubiquitous and secure access to a sensitive system at an appropriate price. The user is looking for a technology that offers a smaller memory footprint, reduced bandwidth and low-power consumption on a low-cost 8-bit MCU, thereby offloading any heavy lifting to desktop and server class machines that can handle content rendering and the central network interface.<\/span><\/p>\n The uNabto web server seeks to reverse the client and server roles. Only such information as is absolutely necessary is stored locally on the device and exchanged with the client. As well as simplifying the software on the embedded device, this greatly simplifies configuration management as all rich content and business logic are stored in a central location.<\/p>\n The system exploits existing technologies from such fields as voice-over-Internet Protocol (VoIP). Three specific node types are:<\/p>\n <\/strong><\/p>\n Figure 1<\/strong><\/span> <\/strong><\/p>\n The embedded device registers itself with the Nabto base station with its designated ID (e.g., gc-3471.medotech.com). A UDP-based awareness signal is periodically transmitted to the base station, serving two purposes, managing the presence of online devices in the base station; and keeping a channel open in the local firewall.<\/span><\/p>\n The user activates an application on the device (e.g., through a bookmark or link on a portal) by requesting the appropriate URL\u2014in this case: nabto:\/\/gc-3471.medotech.com\/report<\/a>.<\/p>\n The Nabto plugin contacts the Nabto base station (the device\u2019s DNS hostname resolves to the base station).<\/p>\n The plugin retrieves an HTML device-driver bundle from the base station (if not already installed). The driver contains all \u2018rich\u2019 content (i.e., graphics, style sheets, layout templates, client side scripts) and descriptions of the services provided by the device in question.<\/p>\n The plugin initiates a handshake with the remote device.<\/p>\n An encrypted handshake is mediated by the base station: cryptographic certificates are exchanged through the basestation and, if both peers authorize one other, encrypted details about each peer\u2019s network configuration are exchanged (specifically, details about each peer\u2019s NAT configuration are exchanged). This information is determined through a process similar to the STUN analysis known from VoIP applications.<\/span><\/p>\n If the network configuration allows it, the client may now communicate directly with the device. If UDP hole punching is not possible due to either peer\u2019s NAT configuration, an end-to-end encrypted relay takes place through the base station instead.<\/span><\/p>\n The plugin maps the user request (in this case, the \u201creport\u201d extracted from the URL) to an opcode as described in the HTML device driver and sends the request to the device.<\/p>\n The uNabto service code on the device receives the request and dispatches it along with decoded parameters to relevant system functionality.<\/p>\n The system computes a response that is encoded and sent back to the client. For the \u2018report\u2019 request, this is simply a sequence of integer three-tuples representing time, measured jaw activity and amplitude of the allied electric impulses.<\/p>\n The browser plugin receives the data from the device and populates the appropriate response layout template from the HTML device driver. The template may reference other static content in the HTML device driver, rendering an HTML page with the final result (Figure 2<\/em>, p. 16).<\/p>\n Figure 2<\/span> The benefits from allowing the dentist to directly interact with the Grindcare device are obvious, particularly if compared with cumbersome manual examination. In addition, off-loading contents from resource-limited devices greatly simplifies maintenance and system development:<\/p>\n It is only necessary to update the device if the request\/response model and\/or the actual system software changes. However, the Nabto technology also simplifies remote firmware update as described later in the Cypherbridge uLoad case study.<\/p>\n The Nabto micro web server and base station can be implemented in a wide range of embedded devices on MCU platforms. System designers can license the Nabto web server code or acquire the code as an integrated part of an optional PIC Ethernet board. The Microchip-based module enables companies to design and prototype web-based systems such as remote medical, industrial and consumer applications.<\/span><\/p>\n Security SDKs such as embedded uSSL and uSSH are well suited to secure FTP, SMTP and similar protocols. The classic desktop content model imposes significant compromises and cost impacts on embedded devices. So-called thin-clients typically are leans content servers and browsers that generally employ many of the same protocols as found on desktop PCs.<\/p>\n Industry experience has shown that such legacy-oriented embedded content servers fall somewhere in a spectrum ranging from price-performance impact for a 32-bit MCU at one end, to unrealistic for 16- and 8-bit MCUs.<\/p>\n The proliferation of MCU devices calls for a device management and firmware distribution package that is both secure and scalable. The Cypherbridge Systems uLoad product provides a comprehensive one that includes an in-chip boot loader, standalone downloader, secure image processing and a multi-point scalable distribution server.<\/span><\/p>\n Cypherbridge has integrated its security, connectivity and device management SDKs with Nabto technology, serving all market segments including 8-, 16- and 32-bit platforms. The uLoad product is offered in a range of integrated packages, including Unified Build, that co-exist with RTOS and TCP, file system, flash memory and network download support, and a standalone build with independent security, download and re-flash capability.<\/p>\n The Cypherbridge uLoad Standalone Build, Micro content server and Nabto device engine contain:<\/p>\n These are just a couple of examples of the benefits of a Nabto content engine. Any trade-off analysis for an embedded content server should include:<\/p>\n NabtoOffloading complexity<\/strong><\/h3>\n
\n
A typical scenario (Figure 1<\/em>) will then unfold as follows:<\/strong><\/h3>\n
![\"\"](\"\/edasource\/december_2010\/images\/197\/eda1012_embedded1_large.jpg\")
<\/a><\/strong><\/div>\n
\nA typical deployment <\/strong><\/p>\n<\/div>\nDevice registration<\/em><\/strong><\/strong><\/h4>\n
User request<\/em><\/strong><\/h4>\n
Encrypted handshake<\/em><\/strong><\/h4>\n
Client\/server communication<\/em><\/strong><\/h4>\n
Rendering of response<\/em><\/strong><\/h4>\n
<\/a><\/div>\n
\nAn example of a rendered HTML response page<\/p>\n<\/div>\nSimple integration and maintenance<\/strong><\/h3>\n
\n
Secure remote update for MCU<\/strong><\/h3>\n
\n
\n
\n<\/em>\u00c5bogade 15
\n<\/em>8200 Aarhus N
\n<\/em>Denmark
\n<\/em>T:+45 8734 5513
\n<\/em>W: www.nabto.com<\/a><\/em><\/p>\n