1. Home
  2. TC10.8 - IOT Architecture for Security

TC10.8 - IOT Architecture for Security

×

Warning message

  • You can't delete this newsletter because it has not been sent to all its subscribers.
  • You can't delete this newsletter because it has not been sent to all its subscribers.

Test Case Title

TC10.8 - IOT Architecture for Security

Goal

The goal for this test case is to present a scenario that enable a secure access to the user for its personal IOT Device. Details on the IOT Architecture are presented to enable a complete end-to-end protected solution

Prerequisites

A snap4city user registered, capability of creating an IOT APP via NodeRED.

Expected successful result

The data retrieved by the registered IOT Device are only accessible to the owner of the device.

Steps

  

 

  1. To demonstrate the test case “IOT Architecture for Security”, go to the Snap4city Portal and make the Login using the snap4city user credentials.
  2. The user is redirect to his/her Main Page. Enforcement about the user identity assure the user acceding his main page is the one that is currently logged against his credentials (password). No others user can access the same Main Page.
     

     
  3. Any modules of the snap4city ecosystem share the same and unique authentication system, based on the same credential. The Keycloak solution is exploited and the enforcement about the identity of the user accessing the different module is therefore delegated to this platform. The exchange of information between the snap4city modules and the SSO system (provided by Keycloak) is made via https communication, basing on the standard Open Id Connect based on top of the OAuth2 protocols.
  4. The user can therefore from its main page acceding/registering its IOT Device as described in “TC11.2: Personal Data regarding IOT Devices on User profile devices and Keys”
     

     


     
  5. User performs the registration of the IOT Device on the IOT directory. During the registration the IOT Directory produces a couple of Keys (K2, K2) meanwhile the user provides the DEVICE NAME ID, the location of the device, etc. The IOT Directory provides/assigns at the device an IOT broker according to the IOT Device Model. This information is accessible for the user, that can insert those values into the IOT device. This approach is viable for devices connected with IOT Orion broker and others Broker;
  6. For SigFOX Devices, the corresponding service WEB portal provides to the user the name (available on the sensor box) and the KEYS, while the URL of the broker is obviously the main SigFOX portal;
  7. During the IOT Device registration, the couple Keys (K1, K2), DeviceNameID, and BrokerURI are saved in the MyPersonalData.
     

     
  8. Since the information (K1, K2, DeviceNameID) are stored in the MyPersonalData and since the modules share the same SSO system, just the user that own a device can, via its IOT Application, acceding its sensor data, as detailed in the “TC11.2: Personal Data regarding IOT Devices on User profile devices and Keys”. The DB storage where data are saved is encrypted so any access from malicious user would not stole any sensible information (TC11.3: Protected storage for Personal Data, Managing User Profile). The user also can manage (delete/download) his personal data as described in “TC11.1: Working with “My Personal Data Type” according to GDPR”
     


     
  9. The IOT brokers which does not provide any authentication out-of-the-box, have been wrapped by using a Proxy Filter Security module that is capable to communicate with module “MyPersonalData and Ownership” which store key and other info in an encrypted database, via HTTPS SSO (secure channel based on TLS and KeyCloak authentication based on JWT Token).
  10. Each request to the IOT Broker has to been validate from the Proxy Filter Security, which check if the user performing the request is authorized, for example for: Subscription, Telemetry from the IOT device, etc.
    Each Message produced by the IOT Broker to other devices and IOT applications is on HTTPS.
  11. Proxy Filter Security can verify the received data with respect to the MyPersonalData Ownership (with the IOT Authorisation and authentication based on KeyCloak).
  12. In summary, the combination of:
  • a unique single sign on system (SSO provided by Keyclock using OPENID CONNECT on top of OAUTH2 protocol)
  • any communication authenticated and authorized via HTTPS
  • the protection/encryption of the User Repository and isolation from the rest of the snap4city ecosystem permits to implement and provide a protected and secure end-to-end solution.
  • Share