Internet Of ThingsUiteindelijk gaat het om de data

Gerard FianenINDES-IDS BV

V 1.0

Agenda

▪ Preventing data loss

▪ Security by Design

▪ Troubleshooting remote IoT devices

IoT architecture

▪ Bandwidth of communication channels

▪ Availability of communication channels

▪ Power loss → Data loss

Mesh net

More about IoT & WAN : TOP presentation

IoT architecture

▪ Bandwidth of communication channels

▪ Availability of communication channels

▪ Power loss → Data loss

Mesh net

More about IoT & WAN : TOP presentation

Mesh netwerken -1

If the router or controller fails, thecommunication channel breaks

Every node self-determines if it is a node orrouter and creates the fastest connection to the gateway

Mesh netwerken -2

Mesh netwerken -3

Single point(s) of failure

• Power

• Service

• Network

• Cloud

IoT architecture : data persistence

▪Local storage

▪ High availability

o Database replication & synchronisation

o Persistent storage

▪ Local processing → less data over comm. channel

Requirements data retention

• Local processing & local database• Database compatibility (SQL)

• On small / cheap / low power targets (battery backup)• In-Memory storage (e.g. Flash)

• Real-Time behaviour

• HA features on edge / node

• Bi-directional synchronization• Security (Encrypted data in database & communication)

DB Client Application

ITTIA SQL Database

Contact table

MS SQL Server Database

Contact table

Embedded Device Server / Workstation

ITTIA Sync Server

TCP ODBC

High availability

High availability is redundancy

Distribute data between databases

High availability use cases- types of replication

Broadcast ReplicationTables in the main database are replicated to all other peers. Only the main database can modify these tables. Broadcast replication can beused to share a global dictionary between all devices.

Two-way Unicast ReplicationTables in the main database are partitioned so that each row belongs to exactly one device. Each row can be modified either in the maindatabase or on one device, limiting the possibility of conflicts. Unicast replication can be used to share device-specific configuration values.

Bidirectional ReplicationEntire tables are replicated directly between devices. Priority-based conflict resolution can be useful when more than two devices share thesame table. Bidirectional replication can be used to share the active state between devices that need to cooperate on the same problem.

MirroringMaintain multiple identical database files, either on separate devices or on different storage media on a single device. No data will be lost ifone storage media or device fails. Also, a copy on a remote device can be used to improve access time for read operations on that device.

ITTIA Sync

Server

High availability - Replication

• Replication log

- Remembers transactions boundary and orders of changes

- Good performance for any number of peers

• Replicate tables with common names and columns

- Columns not in common are ignored, where allowed

- Special columns expose each row’s replication state

Peer column identifies row origin

• Conflict detection and rule-based resolution

ITTIA Sync

Server

We offer expert support to assist and prepare the database schemas

Meer informatie op www.ittia.com

Ittia (www.ittia.com)

In-Memory, distributed, fault tolerant, embedded SQL database ▪ Runs on embedded MCU’s

o Cortex M4 and up

▪ RAM / Flash storage

▪ Host : Linux, Windows

▪ Embedded RTOS integration

o Linux, QNX, VxWorks, Integrity …

▪ High Availability

o Replication

o Journaling

o Persistence

▪SQL + advanced features

▪ UI integration (Qt etc)

▪ Encrypted storage & communication

▪MQTT & DDS integratedMeer informatie op www.ittia.com

MQTT vs DDS

Message Queuing Telemetry Transport (MQTT)

Device-to-Data Center communication.

Most suitable for sporadic messages and

highly resource constrained devices

Data Distribution Service for Real-Time Systems

Device-to-Cloud (Device-to-Data Center)

communication as well as Device-to-Device.

Most suitable for those applications that

require real-time data exchange

MQTT vs DDS

MQTT is optimized for centralized data collection and analysis – connecting sensors and mobile devices to applications running in a data center.DDS is optimized for distributed processing – directly connecting sensors, devices and applications to each other without any dependence on centralized IT infrastructure.

Architectures :

MQTT is hub-and-spoke. Sensors, devices and applications communicate through a message broker running on a server (or appliance) in a data center. All communication routes through this centralized broker.

DDS is decentralized. Things that produce data communicate directly with the applications and Things that consume that data. In other words, peer-to-peer. Data only flows to a data center if it’s required in the data center.

Applications :

MQTT accommodates classic M2M applications, in which a client machine talks to a server machine, one-to-one. An example is remote asset monitoring, such as sensors that monitor oil wells and pipelines.

DDS is best when not all data processing is centralized. For example, consider a patient monitoring system. Sensor data (such as vital statistics) is needed bedside, at a nurse’s station, for electronic health records and even on a physician’s mobile device. It would be incredibly inefficient to route sensor data through a data center to get it to a co-located bedside monitor. It may even be technically untenable due to the aggregate bandwidth requirement.

MQTT vs DDSHowever, while they may share common aspirations, MQTT and DDS are very different standards. Each is optimized around different assumptions about how the IoT will be composed:

MQTT is optimized for centralized data collection and analysis – connecting sensors and mobile devices to applications running in a data center.DDS is optimized for distributed processing – directly connecting sensors, devices and applications to each other without any dependence on centralized IT infrastructure.The differences between MQTT and DDS are manifest in their underlying architectures.

MQTT is hub-and-spoke. Sensors, devices and applications communicate through a message broker running on a server (or appliance) in a data center. All communication routes through this centralized broker.DDS is decentralized. Things that produce data communicate directly with the applications and Things that consume that data. In other words, peer-to-peer. Data only flows to a data center if it’s required in the data center.

Because of their different architectures, MQTT and DDS are suited for different types of applications.MQTT accommodates classic M2M applications, in which a client machine talks to a server machine, one-to-one. An example is remote asset monitoring, such as sensors that monitor oil wells and pipelines.

DDS is best when not all data processing is centralized. For example, consider a patient monitoring system. Sensor data (such as vital statistics) is needed bedside, at a nurse’s station, for electronic health records and even on a physician’s mobile device. It would be incredibly inefficient to route sensor data through a data center to get it to a co-located bedside monitor. It may even be technically untenable due to the aggregate bandwidth requirement.

So, while both MQTT and DDS provide standard communication foundations for the Internet of Things, their architectures lend themselves to very different deployment topologies. Choosing a centralized solution when your data flows are distributed could have a profound impact on your applications’ scalability and efficiency.

IoT Security - Legal

Europe (GDPR) ,

– In effect with fines of €20M or 4% global

The Netherlands (AVG)

UK Government (DCMS)

- Legislated enforcement within 3 years with GDPR type fines

- Published Code of Practice for Consumer IoT Security

- 13 Codes of Practice

ETSI

– Reiterating UK DCMS guidelines

EU (ENISA)

– >150 baseline recommendations

IoT Security by design

Seminar / workshop : www.embedded-masterclass.nl

It all starts with the requirements !

The right tools simplifySecure by Design

1) No default passwords✓2) Implement a vulnerability disclosure policy 3) Keep software updated ✓4) Securely store credentials and security-sensitive data ✓5) Communicate securely ✓6) Minimise exposed attack surfaces ✓7) Ensure software integrity ✓8) Ensure that personal data is protected ✓9) Make systems resilient to outages ✓10)Monitor system telemetry data 11)Make it easy for consumers to delete personal data ✓12)Make installation and maintenance of devices easy ✓13)Validate input data ✓14) Keep verifying for vulnerabilities

Best Practices guides

IoT Security Foundation www.iotsecurityfoundation.org– Initially UK-centric, now the global forum for IoT Security

Root of Trust

• Definition of Root of Trust (RoT) – “The minimal set of software, hardware and data that is implicitly trusted in the platform ...”

• The secure MCU/hardware must have: – Unique identity (silicon serial number) – Lockable memory (Flash) to allow the programming of certificates and keys – Secure memory management to allow software to be securely programmed and protected

• Secure Boot Manager (SBM)– Ensure that software loaded into unsecure memory has been correctly signed (authentication) and is decrypted prior to Flashing – Verification of application code prior to execution (signature checking, hashing)

• The Root of Trust enables the building of a Chain of Trust

Establishing the Chain of Trust (CoT)

• With an immutable boot loader and a secure area of memory we can now implement a CoT

• The CoT is created using Certificates

• The Device Certificate creates identity by tying the IoT device unique ID to a Public key

• The Intermediate Certificate authenticates that IoT device to the OEM

• The OEM is authenticated by the Root certificate which is beyond reproach

IoT Security by design

More about certificates and the chain of trust : presentation Wim Bos - Luminad

Pfff, that is all very complex !

• Security is the leading barrier for IoT adoption *

• Over 70% of enterprise customer would purchase more IoT

devices if security addressed *

• <4% of new IoT devices include embedded security **

• Massive lack of cybersecurity skills across industry

• Applications need to remain secure across entire lifecycle to

comply with new legislation

*Bain & Co.“Cybersecurity Is the Key to UnlockingDemand in the Internet of Things” (2018) ** ABI Research 2018

Security in the design-flow

Ideally it should be possible for one person to cover the whole process

Embedded Trust TM

IoT Security by design

In 2019 geven wij een seminar over deze tools ism www.embedded-masterclass.nl

DB Client Application

ITTIA SQL Database

MS SQL Server Database

Embedded DeviceServer / Workstation

TCPSecureSocketLayer

AES-128AES-256

AES-128AES-256

SecureSocketLayer

Protects against :EavesdroppingUnauthorized interceptionSession high-jacking

Securing the data

Remote Device Monitoring - 1

AWS IoT Core AWS SDK

Software is never bug free… Will your IoT product stand the test of reality?

Become aware of issues in deployed devices and get traces for analysisAllows for fixing the issue quickly, via an OTA update, before most users are affected

AWS IoT

Percepio DFM Classification Engine

AWS S3

Notification

Analyze the issue

Over-The-Air Update

IoT Product Company

Trace

Alert Signature

Tracealyzer/DFM

Percepio Cloud Account

Customer Cloud Account

List of Alerts

Trace

New/Important Issue?

Alert

IoT Device withDFM firmware agent

IoT Product Fleet

Developers / QA

• Alerts generated by e.g. asserts and fault handlers• Compact trace format – less than 5 KB needed• Data can survive a crash – uploaded after restart

Remote Device Monitoring - 2

Meer op : www.percepio.com/dfm

This is just 5 KB of trace data, 350 ms trace, during a busy period, with many details.

30

Multi-threading and timingContext switches, internal kernel eventsExecution time, response time, periodicity…

API calls (OS, Middleware stacks, Drivers…)

Call sequences and timingParameters and return valuesBlocking and timeoutsObject dependencies

Application loggingDebug messages, variable values…

Time between eventsState changes over timeDetect errors

e.g. deadlocks

Meer op : www.percepio.com

INDES –Integrated Development Solutions BV

www.indes.com info@indes.com Gerard@indes.com

IoT gateway met Wirepas IoT Device management IoT Secure platform Cloud Device Firmware Monitor