DJ007 DJ007 - 1 month ago 7
Python Question

Generate a unique code using date and time

First of all sorry for my bad english.

I'm working on a project and I need to generate a code (ID) that I can verify later.

As my project is very extensive I will give you and example and later what I need to solve.

Example: I have a code that get the temperature of a place once a day, and the data is stored in a local database (I save the temperature, the date, and the unique ID).
The code is encrypted (No one can see the source code of the program).

Now my problem.
I need to be sure that the data stored in my database has not been modified.

What I think can solve this is: For example, the date is 08-19-2017 and the temperature is 25°C. I can do some math operations (for example, multiply all) and get an ID, and later on I can verify if the code match the date and temperature.

Do you think this is a good solution or is there a better one?

Thanks all.
I'm using Python and linux.

Answer Source

The code is encrypted (No one can see the source code of the program).

That's a fallacy. Unless you're using a secure processor that can actually decrypt things into memory that can't be read by the operating system, your program is never truly encrypted. Sure, the original python might be hidden, but from the assembly, a somewhat skilled person can easily gather what is happening.

So, since this is kind of a data security question: Security by obscurity doesn't work on general-purpose hardware. Especially not with relatively high-level things like Python.

Now my problem. I need to be sure that the data stored in my database has not been modified.

That is a hard problem, indeed. The problem is that: if someone's able to fully reconstruct the state of your program, they can also reconstruct what your encryption would have done if the data was different.

There's a few ways around that. But in the end, they all break down to a single principle:

You need some hardware device that can encrypt your data as it comes and proves it hasn't been tampered with, e.g. by keeping a counter of how many things have been encrypted. So, if you have e.g 100 things in the database that have been encrypted by your secure, uncloneable crypto hardware, and it shows it has only been used 100 times, you're fine. The same would apply if that hardware would, for example, always do "encrypt(input bytes + timestamp)".

You can't do that in software on a general purpose OS — software can always be made to run with modified data, and if it's just that you patch the physical memory accessed just in time.

So, what you'll need specific hardware. Feels like a crypto smart card would be able to do something like that, but I don't know whether that includes the functionality to keep a counter or include the timestamp.

One solution that might work is basically using a stream cipher to ensure the integrity of the whole data "stream". Here, part of the secret is the state in which the encryption algorithm is in. Imagine this: You have a smart card with a secret key from a keypair generated on the card itself on it. You hold the other key in your cellar.

  1. You, before shipping the device, encrypt something secret. That puts the smartcard in a state that the malicious tamperer can't guess.
  2. You encrypt the first value, save the output. That changes the internal state!
  3. You encrypt and save the output of a known word or sequence
  4. repeat 2. + 3. for all the other values to be stored.

at the end, you decrypt the data in the database using the key you kept in your cellar. Since the internal state necessarily changed with the input data (i.e. encrypting the same data twice doesn't give the same result!!), the data isn't correctly decryptable if you something is missing from the records. You can immediately check by the output generated by the known word.


takeaway

What you're trying to do is hard – that namely being:

running software on hardware that you have no control over and having to ensure the authenticity of the data it produced.

Now, the impossible part is actually making sure that data hasn't been tampered with before it enters your software – who says that, for example, the driver for your temperature sensor hasn't been replaced by something that always says "-18 °C"? To avoid the capability of people to tamper with your software, you'll need hardware that enforces the non-tampering. And that's not something you can do on PC-style hardware, unless you disable all debugging possibilities and ensure you have safe booting capability.