1

I'm curious what is the most widespread way nowadays to sign the telemetry message from a software program to prove its authenticity to the receiver?

Imagine the software (which can run on-premise, at customers PC) creates a telemetry record. With the customer's consent this record is send to the vendor server. The customer is aware of the message content (due to the legal reasons) and knows to which API it is send (because everybody can use traffic sniffers).

How the vendor can be sure that the telemetry message is genuine, originating from their software? The goal is to reduce the risk of malicious manipulation of the telemetry message.

The first that come into the mind is embed the secret key to the software, use it to sign the telemetry message. The receiver checks the signature using the private key and discard the message if the signature is not valid.

To achieve that the software assembly line must provide fresh private key at least for each release of the software, so the signing key remains fresh.

The apparent risk is leakage of the signing key. Since it will be embedded in every copy of the software and the software is shipped to the customer, there is no guaranty that it stays secret. The risk of the key leakage can be reduced by the short key validity time. But it can not be shorter then the valid usage time of the software version itself (1-2 years). So the risk of key leakage remains.

Is this a working approach? Are there are any other disadvantages of suggested scheme, which I don't see at the first place?

Anton Golubev
  • 131
  • 4
  • If you want to prevent data manipulation you have to prevent user access to the OS, which effectively meany you can only provide cloud services running in a cloud you control. On premise installations are executed in an untrusted environment from your perspective so all data that is transmitted from such a system have to be considered as potentially compromised or manipulated. – Robert Apr 10 '22 at 20:24
  • Sounds like you are looking for HMAC no? https://security.stackexchange.com/questions/20129/how-and-when-do-i-use-hmac That seems to meet your requirements, and there are existing libraries for implementation. – Rodrigo Murillo Apr 10 '22 at 22:12

2 Answers2

2

It's impossible.

The customer has to be able to send legitimate telemetry messages, so the customer will thus also be able to send forged telemetry messages.

In other words, it is not possible to create a telemetry endpoint, which will not also receive forged messages.

However...

Why would customers want to send forged telemetry messages? Most telemetry messages contain data such as the exact product version, build number, date and time, operating system, etc...

The customer doesn't really have an advantage to lie about the Windows build they're using, so why would they?

  • It may be well impossible to guaranty mathematically the genuity of the message origin, since the sending process is in the hand of sender, but the question (as often with the security topics) is about finding the right balance between costs and utility by using the adecvate technology, e.g. making is unattractive/costly enough not to try. – Anton Golubev Apr 10 '22 at 14:53
  • About the "why". We share aggregates build on the telemetry data with the customer (their own) so they can improve their processes around using our software. Sometimes customers fiddle with the data. Not necessary a malicious attempt, but some "noise", which you always have if you have enough large user-base. We just want to be sure that the data are as clean as possible. – Anton Golubev Apr 10 '22 at 14:53
  • Another concern is which is often repeated by security audit is a non-customer wrong-doing: currently everybody in the internet can fake the telemetry message for whatever bad purpose (e.g. to hack apps, which expose telemetry aggregates to customers). Companies like Microsoft, Apple effectively protect themselves from such fake messages. So the practical solution does exist? – Anton Golubev Apr 10 '22 at 14:55
  • 1
    @AntonGolubev I would assume that your understanding what a telemetry system is supposed to do is different for the IT industry. First I have not heard that any IT company shares telemetry data with their customers. Second, the companies you have mentioned have a very large set of customers which allows to apply statistical measures to filter out inconsistent messages. Unless a few thousand systems are sending the same fake messages such systems should work fine. – Robert Apr 10 '22 at 20:21
  • @AntonGolubev `Companies like Microsoft, Apple effectively protect themselves from such fake messages.` - Citation needed. –  Apr 10 '22 at 20:44
  • 1
    I think you are describing a use case for HMAC. https://security.stackexchange.com/questions/20129/how-and-when-do-i-use-hmac If you want message integrity and authentication. – Rodrigo Murillo Apr 10 '22 at 22:17
  • @RodrigoMurillo HMAC requires a key to be stored in the program (so the program can create the right hash), thus again the user will have access to the key –  Apr 10 '22 at 23:13
  • @MechMK1 In this patent for example Microsoft tries to solve the problem of genuity of the telemetry message by using public/private key infrastructure https://patents.google.com/patent/EP2321779A2/en. I hope it suffice as an indirect proof. – Anton Golubev Apr 11 '22 at 11:10
  • @RodrigoMurillo would you go for simple HMAC signature added to every telemetry message signed using a static secret key embedded into the app or use public/secret key to sign the message? I cannot figure if there are any practical benefits of using PKI vs shared secret in this scenario. – Anton Golubev Apr 11 '22 at 11:15
  • So @AntonGolubev, yes I would consider a HMAC and shared keys here. The client needs to set the key, manually or have the app generate them (better) , and send them to your server. – Rodrigo Murillo Apr 11 '22 at 23:29
  • 1
    HMAC provides non-repudiation, message integrity and authentication. It allows you to validate integrity and authenticity of the message. I don't read the OP as saying client message forgery is a real risk or threat. Yes the client has the key. That's not a risk we need to worry about here, as the benefits of HMAC outweigh any risk of client forging his own messages, which is unlikely to be a real concern – Rodrigo Murillo Apr 12 '22 at 04:16
2

How the vendor can be sure that the telemetry message is genuine, originating from their software? The goal is to reduce the risk of malicious manipulation of the telemetry message.

You can't. You're basically asking how to implement DRM on a system you don't control, and that's not possible.

A determined attacker with root privileges on the system will always be able to forge telemetry messages. But there are lots of things you can do to make it harder, such as:

  • Obfuscating your code
  • Adding jailbreak/root protection if it's on a mobile device.
  • Detecting virtualisation software, debuggers, packet sniffers, etc and refusing to run the software.
  • Adding anti-debugging protection.
  • Implementing certificate pinning and attempting to detect and break TLS decryption (which will mean your application won't work in most enterprise networks).
  • Encrypting and signing the messages with a key in the client (perhaps related to their license key, so that you can work out who it is).
  • Frequently changing all of the above methods so people have to keep redoing all their reverse engineering work.
  • Mapping telemetry messages to the IP addresses of your users and rejecting any that don't match.
  • Performing server-side monitoring to detect any suspicious activity (messages sent outside of the usual hours/patterns, invalid message types, messages sent in impossible sequences, messages with tampered bodies, etc).
  • Revoking the licenses of any user who you detect trying to mess around with this.

And after all that work, it'll still be possible for people to spoof messages if they really want to, and you'll have made it much harder to diagnose and debug any issues.

Gh0stFish
  • 4,664
  • 14
  • 15