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?

Improve this question
2
  • 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, 2022 at 20:24
  • Sounds like you are looking for HMAC no? security.stackexchange.com/questions/20129/… That seems to meet your requirements, and there are existing libraries for implementation.
    – Rodrigo Murillo
    Apr 10, 2022 at 22:12

2 Answers 2

Reset to default
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?

Improve this answer
11
  • 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, 2022 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, 2022 at 14:53
  • 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, 2022 at 20:21
  • 1
    I think you are describing a use case for HMAC. security.stackexchange.com/questions/20129/… If you want message integrity and authentication.
    – Rodrigo Murillo
    Apr 10, 2022 at 22:17
  • 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, 2022 at 4: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.

Improve this answer

You must log in to answer this question.

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