Skip navigation
> RoadTest Reviews

Azure Sphere Guardian 100 - Review

Scoring

Product Performed to Expectations: 10
Specifications were sufficient to design with: 10
Demo Software was of good quality: 9
Product was easy to use: 9
Support materials were available: 8
The price to performance ratio was good: 9
TotalScore: 55 / 60
  • RoadTest: Azure Sphere Guardian 100
  • Evaluation Type: Development Boards & Tools
  • Was everything in the box required?: Yes
  • Comparable Products/Other parts you considered: Electric Imp and Particle.io for integrated managed cloud services. OSD32MP15x System-in-Package seems to be a close match for chipset and features
  • What were the biggest problems encountered?: Understanding where this product rightfully fits within a brownfield application, as in what does it take to make it work securely - all you get is marketing material, which is not helpful from technical standpoint. Then I found there were a couple of errors within AVNET documentation that caused confusion, especially with the initial setup to claim my device.

  • Detailed Review:

     

     

    THIS ROADTEST IS NOT COMPLETE. AS THERE IS NO "SCHEDULE FOR PUBLICATION" WITH ROADTEST CREATION THE "CTRL-S" SHORTCUT ONCE AGAIN CAUGHT ME OUT.

     

     

    1.0     Introduction

     

     

    The AVNET Guardian-100 is an “Edge device” which is securely integrated with Avnet’s IoTConnect cloud-based platform. The Guardian 100 is based on the Avnet Azure Sphere MT3620 module, which uses the MT3620AN SoC (System on Chip). The device provides an Ethernet and/or USB interface with existing equipment, plus secure dual-band Wi-Fi connection to the internet. The 5V power supply is via the USB Type-B connection only.

     

    The AVNET Guardian-100 is positioned as an edge device, suitable for brownfield applications where you can retrofit and provide secure connectivity without exposing the existing unconnected network to the outside world. The product datasheet goes on to say that “Beyond retrofitting existing devices, Avnet Guardian can also be used in scenarios where current connectivity does not meet enterprise-level security requirements. Avnet Guardian is a good fit for any industry that operates using mission-critical, capital-intense equipment.”

     

    So, dare I say it, but the AVNET Guardian-100 may well be suitable to bridging that “air gap” between the public Internet and a secure SCADA or Local Area Network or standalone device. Of course that claim can only be made for the hardware as bridging this gap securely still relies on human effort and competence to ensure that the software does not unwittingly open up a “front or back door”.

     

    I was therefore curious to see whether the Guardian 100 was the best configuration for this purpose, as the only hardware interface provided to the user for an application is USB (serial) and Ethernet (TCP/UDP) connectivity.

     

    Let's find out.

     

     

    2.0     Hardware Review

     

    Unboxing

     

    The device is neatly packaged within a gloss white box which has the AVNET logo and the tag line “Reach Further” printed on the lid. There is a stick on label containing a “SER” number, a MAC address and a QR code, which when scanned provides a longer (presumed) serial number and the same MAC address. On the reverse side of the box there is some health warning (with URL link to www.P65Warnings.ca.gov) and FCC compliance labelling.

     

     

    The box opens landscape and you are then presented with a quick start guide (leaflet), which happens to be in portrait. Underneath the leaflet we find the Guardian-100 Edge device, which is neatly slotted into a foam insert.

     

    {gallery:autoplay=false} Guardian 100 packaging

     

    Removing the foam insert, we find 2 x USB cables and 1 x Cat 5 Ethernet cable. One of the USB cables is a micro-USB to USB type-A (male-male) cable, which is used for debugging and sideloading firmware, and the other is a USB 2.0 type-A to type-B cable (male-male) cable, which is used for power and for connecting to external brownfield devices. The USB 2.0 type-A to USB type-B cable is a decent length (6ft / 1.8m), which is great to see.

     

     

     

    Also included in the box are 2 x 3M VHB adhesive mounting pads and 4 x mounting feet with 3M adhesive and 2 x mounting screws (as shown below).

     

     

     

    Teardown

     

    The PCB (AES-MS-MT3620-GUARD_PCB-REV A) is housed within a flanged enclosure which has a click-fit screw mounted lid. On the lid we have 4 LED indicators, one for power (green) and three others (amber) for user control. The enclosure itself has a nice black matt finish.

     

     

    Inside the enclosure the black PCB is mounted with 4 screws. As shown on the block diagram, this PCB includes a number of modules:

    • MT3620 Azure Sphere Device
    • FTDI FT4232HQ USB 2.0 to UART IC
    • MCP2200 USB to UART Converter
    • ENC28J60 SPI to Ethernet Converter

     

     

    {gallery:autoplay=false} Inside Guardian 100 enclosure

     

    The Azure Sphere Guardian 100 Hardware User Guide (page 9 of version 1.3) provides us with a great use example. So when looking at the block diagram there was nothing obvious that answered my million dollar question, which is  “Can this Guardian-100 device really ring fence a "brownfield" network or device when it's hooked into our standalone network or device and it is communicating with the Azure cloud and/or the Internet”.

     

     

    To get my head around this question I had to come up with a way to formulate a system architecture using modules I had. So, on a conceptual rather than purely technical level, I came up with the following design:

     

     

    Thus for the Guardian 100 to deliver what I thought would be necessary, it would be similar to having a CooCox EmbeddedPi module, but with a high performance or multi-core MCU that could be used as the interface to a brownfield network via an Ethernet (TCP/UDP) and USB/Serial connection. This brownfield network interface controller would then be able to collect data from, and possibly send commands to, this network. This controller would then take this data and dispatch it to an edge device, which in my model is a Raspberry Pi, using an ultrasecure and encrypted method to prevent any eavesdropping thereby protecting the integrity of the unconnected network. The Raspberry Pi would then operate as the Gateway Device with secure encrypted Internet connectivity to the Azure cloud.

     

    Well, I soon discovered that the Guardian 100 does this far more elegantly. According to the Microsoft Azure documentation, the hardware architecture provides a fundamentally secured computing base for connected devices. An Azure Sphere crossover MCU consists of multiple cores on a single die, as shown in figure below:

     

     

    As per the datasheet, the Avnet Azure Sphere Module based on MT3620AN SoC provides good processor speed and a decent amount of memory resource:

    • 1x 500MHz ARM Cortex A7, 4MB SRAM
    • 2x 200MHz ARM Cortex M4F cores, 192KB TCM, 64KB SRAM (per core)
    • On-chip QSPI flash memory (16 MB)

     

    The Microsoft documentation goes on to say “Each core, and its associated subsystem, is in a different trust domain. The root of trust resides in the Pluton security subsystem. Each layer of the architecture assumes that the layer above it may be compromised. Within each layer, resource isolation and compartmentalisation provide added security.”

     

    Then there are numerous ways to architect your firmware on the hardware. Firstly, there is the high-level application core and then there are two real-time cores. Then there are internal hardware firewalls. These are silicon countermeasures that provide “sandbox” protection to ensure that I/O peripherals are accessible only to the core to which they are mapped. The firewalls impose compartmentalisation, thus preventing a security threat that is localised in the high-level application core from affecting the real-time cores’ access to their peripherals.

     

    I suppose the bad news is that you can still mess this up through a badly designed software application. It is up to you to utilise the security features embedded within the hardware, such as a security processor core, cryptographic engines, a hardware random number generator, public/private key generation, asymmetric and symmetric encryption, support for elliptic curve digital signature algorithm (ECDSA) verification for secured boot, and measured boot in silicon to support remote attestation with a cloud service, as well as various tampering counter-measures including an entropy detection unit.

     

    So the MT3620 + the OS architecture looks really promising. It just means (obviously) that you have to know what you are doing.

     

    Let's now dig a little deeper to understand whether this device has to be treated as a peripheral on the brownfield network or needs to act as a central or hub device, like a server.


Comments

Also Enrolling

Enrollment Closes: Apr 14 
Enroll
Enrollment Closes: Apr 8 
Enroll
Enrollment Closes: Apr 28 
Enroll
Enrollment Closes: Apr 27 
Enroll
Enrollment Closes: Apr 14 
Enroll