View
3
Download
0
Category
Preview:
Citation preview
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
Recommended