Can you list the entities involved in the case of smart meters -IOT

Question 1: Can you list the entities involved in the case of smart meters?

Smart meters don’t all use the same protocols to communicate, and the standards often vary by region. There are several protocols smart meter manufacturers should be familiar with, including:

• DLMS/COSEM
• ANSI C12.18
• Open Smart Grid Protocol (OSGP)
• TCP/IP
• UDP/IP
• MQTT
• CoAP
• HTTP
• Websockets
• XMPP

 

Question 2: Can you list the M2M Security Threats?

 

Device triggering attack

Denial of service attack

Access priority attack

External interface attack

The device triggering attack occurs when an attacker sends falsetriggering signal and activates M2M device to connect to a falsenetwork. This situation becomes worse when a massive number ofdevices are activated by fake signalling message. However, changingaccess priority code degrades the service performance of M2M usersand insecure external interface can leak sensitive information. The3GPP proposes MTC security architecture and analyzes its potentialvulnerability and threats. In their technical report TR 33.868 [10][8],the following security threats in MTC network are mentioned.•False network attack: When a MTC UE is in a detachedstate, the attacker can impersonate a network to send a triggerindication to the MTC UE. False network attack is similar todevice triggering attack in which attacker can awaken a MTCUE and waste its power and also obtain personal informationof a particular device.

•Tamper attack: If an attacker tampers the TCP/UDP port of theMTC application server, the MTC UE may establish wrongconnection with this server and get rejected. It will wastepower consumption and increase transmission delay.

•SMS spoofing: When the SMS is used for triggering the MTCUEs, spoofing SMS causes serious threats to the devices whichhas limited power supply. Spam SMS contains false triggerindication message which wastes network resources in the permanent interruption of the communication channeland therefore represents a DoS attack against wirelesscommunications.

•Scrambling: attacks normally target more precisely specificframes or parts of a frame and takes place during smaller andwell defined periods of time.

•Eavesdropping: Since the wireless medium is essentially abroadcast medium, any attacker may just be able to eavesdropon ongoing transmissions and decipher the contents.

•Exhaustion: It is a typical attack launched at the physicallayer is to exhaust the radio power supply. Exhaustiontypically happens due to collision, overhearing, idle listening,retransmission, and interrogation of the transmitted andreceived packets

Question 3: Can you explain the M2M Security Requirements?

 

7.1 Appropriate level of security. Each service shall be able to perform authentication independently of

other services. For M2M Devices connected via an M2M Gateway, the authentication of the M2M

Device may be performed directly to the M2M System or to the authenticated M2M Gateway.

7.2 Authentication of M2M service layer capabilities or M2M applications: When there is a

request for data access or for M2M Device/Gateway access, the M2M Device or M2M Gateway

shall be able to mutually authenticate with the M2M Service Capabilities or M2M Applications

from which the access request is received.

7.3. Data transfer confidentiality: The M2M System shall be able to support appropriate

confidentiality of the data exchange. A particular M2M application may or may not require the use

of such confidentiality.

7.4 Data integrity: The M2M System shall be able to support verification of the integrity of the

data exchanged.

7.5 Prevention of abuse of network connection: M2M security solution should prevent

unauthorized use of the M2M Device/Gateway.

7.6 Privacy: The M2M System shall be capable of protecting privacy.

7.7. Device/Gateway integrity validation:

The M2M System shall be able to support a mechanism for M2M Device/Gateway integrity

validation. The M2M Device/Gateway may or may not support integrity validation. If the M2M

Device/Gateway supports integrity validation and if the device/gateway validation fails, the

device/gateway shall not be allowed to perform device/gateway authentication. The mechanism for

device/gateway integrity validation may be initiated upon query from the M2M System or may be

autonomously started locally by the M2M Device/Gateway at any time. The M2M System may

remotely get the historical log of tamper detection in a M2M Device/Gateway if supported by the

device/gateway.

7.8 Trusted and secure environment

M2M devices that require device integrity validation shall provide a trusted execution environment.

The Trusted Environment (TrE) shall be a logical entity which provides a trustworthy environment

for the execution of sensitive functions and the storage of sensitive data. All data produced through

execution of functions within the TrE shall be unknowable to unauthorized external entities. The

TrE shall perform sensitive functions (such as storing secret keys and providing cryptographic

calculations using those secret keys) needed to perform M2M device integrity check and device

validation.

7.9 Security credential and software upgrade at the Application level

Where permitted by the security policy, M2M System shall be able to remotely provide the

following features, at the Application level:

i. Secure updates of application security software and firmware of the M2M Device/Gateway.

ii.Secure updates of application security context (security keys and algorithms) of the M2M

Device/Gateway

 

Question 4: Can you explain the Bootstrapping Requirements?

 

 Bootstrapping refers to the process of assigning identity to the device and enabling communications with an endpoint. Devices in a global fleet should be provisioned in the regional data center nearest to its physical location for minimum latency. Each device should get its regional endpoint and certificate no later than the time of bootstrapping. Each device is provisioned in the nearest to its physical location and gets the certificate and IoT endpoint at the time of bootstrapping. This ensures best possible latency for bidirectional communications.

Recommendation 25.5.1 - Obtain key metadata and regional endpoint for the device at the time of bootstrapping

• The device signs its thing name with a private key and sends a provisioning request to a pre-defined cloud endpoint. If the device uses its own private key, it provides a certificate signing request (CSR) in the provisioning request. If a CSR is not present in the request, AWS IoT creates the private key.
• IoT services in the cloud receive and validate the request and thereafter, provision the device.

Recommendation 25.5.2 – Use automated mechanisms to audit the configuration of your devices, monitor connected devices to detect abnormal behavior, and mitigate security risks

• For example, use AWS IoT Device Defender to continually audit your IoT configurations to make sure that they aren’t deviating from security best practices.

Recommendation 25.5.3 – Use temporary, limited-privilege security tokens to communicate with cloud services

• For example, AWS IoT provides the credentials provider feature that allows a caller to authenticate AWS requests by having an X.509 certificate. The credentials provider authenticates a caller using an X.509 certificate, and vends a temporary, limited-privilege security token. The token can be used to sign and authenticate any AWS request.

 

 

Question 5: Can you explain the Identity-Based Encryption Solutions?

 

The input to AESIM is control information or unencrypted data. Encrypting all this information can overload an embedded device's processor, and also limit the ability to separate the data fields so that the system can communicate. The goal of the AESIM technique is to format this information and encrypt the field's values. The AESIM output will be an AESIM message. AESIM message length is not limited to the maximum size. An AESIM message is a basic unit of data exchange between an IoT device and the system's cloud server. Depending on the length of data to be transmitted, it may split into a group of segments in a predefined sequence in the system. Each message has its own message header identifier. For example, the 3-character code "AMH" contained within the header of each message identifies its type.

 

An AESIM message segment is a logical group of fields. At the beginning of each message segment, there is also a segment classification code. Segment classification symbols are up to 6 characters in length. Following that, in each segment there are data fields. Each data field has a field name and its value. Between the field name and the field value is separated by a "^". At the end of each AESIM message is a Message Key of 16 characters long. The Message Key is predefined between the cloud server and the gateway devices, which has the role of authenticating the message sent from the IoT device to the server to be a message of this IoT system, so that it can help the server. Authentication checks before decrypting the values ​​of the data fields inside the AESIM message.

 

Since AES only works with data blocks (input and output) of 128 bits and keys of length 128 bits, the important data fields before encryption in this technique need to be divided into blocks of length Maximum data is 16 characters. If the block data is less than 16 characters in length, the default will suffice for adding empty characters before it. Fields in an AESIM message are separated by a space "|". Sign "|" Used to separate data fields, if there is no data field it is treated as empty field. For fields that carry sensitive critical information, the data value will be AES-128 bit encrypted, and written to its correct place before encryption in the hexadecimal character string format. (HEX). The name of the data field does not need to be encrypted to reduce the amount of encryption computation for the device CPU. The Message Key at the end of the message also needs to be encrypted with the AES-128 bit algorithm with the same AES secret key.