I am doing a security assessment on the communication security of a legacy IoT device. The objective is to assess and find security gaps in the current design/implementation.

The mode of assessment is manual, primarily with the reference of existing design and code. This is only client-side at device; while server is a cloud-based server. The device is using a GSM module (SIMCom SIM900) and makes HTTPS communication to server over internet using GSM AT commands.

Based on my understanding on SSL/TLS, I am considering below parameters or criterias for this assessment:

a. TLS protocol version

b. Cipher suites used

c. certificate and key management

d. Root CAs installed on the device

e. Embedded PKI aspect for device identity management

f. Hardware crypto aspect (SHE/TPM)

Am I doing it in a right way? Though I think above list of parameters are not specific to Device HW/SW platform; rather generic. but I guess that's how it should be! I mean parameter list will be pretty much same; however actual assessment on these will depend on security requirements and other aspects like device footprint & its platform etc.

Is the assessment parameter list I am considering is good and adequate?

1 Answer 1


This is a good start, but a thorough assessment would need to go much deeper than this. For example:

  • How does the client generate random numbers? Does it use a CSPRNG? Or, does it use a weak random number generator, like the one used in early versions of Netscape Navigator, where a passive attacker was able to guess the random numbers generated for the session keys, and thus decrypt the ciphertext going over the network.

  • Does the client leak information when it encounters a padding error? If so, then it might be susceptible to a padding oracle attack, as was the case with the Steam Gaming Client.

  • How does the client implement ECDSA? Does the client generate a new random k for each signature that it creates? If not, it may be possible for a passive attacker to calculate the private signing key after observing a few signatures, as was the case with the Sony Playstation 3.

These are just a few examples. But, as you can see, subtle mistakes in the implementation of cryptography can have disastrous consequences. This is why cryptography is so hard to get right.

  • Thanks mti2935 ! However isn't it like randon number generator, check on padding error, implementing ECDSA are ALL taken care by underlying SSL/TLS library? I understand that developer doesn't need to manually implement all these himself! Aug 16, 2020 at 4:37
  • If the device uses a library, that's good. But, there have been many libraries that did not implement one or more of the above properly. So, perhaps you'll want to add to your list: g. check for any known bugs in crypto library.
    – mti2935
    Aug 16, 2020 at 11:13
  • @mit29935 Ok, sounds good. Thanks much!! Aug 16, 2020 at 13:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .