2

I want to prove that the source code I am using is the same as the open-sourced version, which is publicly available. My idea was to publish a hash of the open-sourced version and compare it to the hash of the deployed server at boot. However, because the open-sourced hash is available pre-deployment, it is possible for a bad actor to hard code the hash into the server and avoid the hash function.

Is there a way I can prevent this from happening? I found that Heroku is using a similar approach where they are fetching the commit hash. Is this tamperproof? And if so, how is this different from my approach?

7
  • 2
    I think that you are missing a lot of context. Who do you want to prove this to and why? Where is this bad actor? How is the bad actor able to "avoid the hash function"? – schroeder Sep 30 '20 at 10:17
  • @schroeder Thanks for your quick reply. I am building a decentralized marketplace (proof of concept); I have mitigated central data storage but I have yet to mitigate data governance. I am not sure if achieving this is even possible, but I would like to prove that I am running the correct data governance source code for my auth server. It's a trustless setup. – Ryan Shahine Sep 30 '20 at 10:26
  • 1
    So, why not copy the source code from the source, hash it. Security store the source code in read-only storage, then compare the hash to your production code? – schroeder Sep 30 '20 at 10:43
  • @schroeder Again, thanks for your quick reply. What I meant by avoiding the hash function is declaring a var which overrides the result of the hash function. Because you already know the output, you can hard code it. My repo can be found here: github.com/ryanshahine/sha256-signed-server - One could declare a second readable_hash var after the first one and override the result. The person in charge of the auth server could be the bad actor (so, myself in theory). – Ryan Shahine Sep 30 '20 at 11:05
  • I still don't think that you have provided enough detail or context. I have no idea what is going on in your scenario. As a result, this looks like an XY Problem. Where is the code? Who has access to it? Who has access to the outputs? Start from the beginning. – schroeder Sep 30 '20 at 11:33
2

This is essentially an impossible task.

If you have read Ken Thompson's "Reflections on Trusting Trust", then you already know everything I am about to say. If not, please keep reading:

Imagine I publish an open-source project, that is written in some language, and simply takes input and returns the input unchanged - like a very simple version of echo. You download my source code, read through it all (it's just a few lines long anyways) and then you compile it. You can be sure that your program does exactly what you think it does, right?

Wrong.

How do you know that your compiler didn't add any extra instructions, such as checking whether or not the input's sha-256 hash is e257f6eccac764b6cea785a0272e34d3dbc56419eac2ad436b9fb4bddcd10494 and if it is, do something unexpected.

You might say that that is unlikely, but you cannot ever be fully certain of it. But perhaps you want to be fully certain of it, right? After all, you want to cryptographically prove that the software you are running does exactly what the source code says it should do. So you inspect the binary with a reverse-engineering tool, like Ghidra or IDA Pro. But...how can you be sure these tools do what you think they do? Sure, on the surface they might seem as if they show you the binary as it is, but how can you be sure that they don't hide the maliciously inserted code from you?

You could completely forego existing compilers and write your own in bytecode, byte by byte, instruction for instruction, but how would you do that? You need some program that writes those bytes to disk. How do you know that those are not infected and write some extra bytes?

And even if you completely forego programs and just use a magnetized needle and a steady hand, how can you be sure that your CPU actually runs the instructions you want it to run and doesn't run some extra instructions? After all, CPUs run microcode these days, which is difficult to inspect.

In summary...

... it's extremely hard to prove that a computer does what we think it does. Can you show some hash of some source code or deployment state to show something to your customers? Of course you can. But that really doesn't mean anything.

6
  • This assumes compiled code. – schroeder Sep 30 '20 at 10:50
  • It's the same with interpreted code, really. The interpreter would be the thing that is compiled then. And if the interpreter is written in an intermediate language, take whatever is running that IL code and interpreting it as binary – MechMK1 Sep 30 '20 at 10:56
  • 1
    That doesn't appear to be what the OP is asking for. The concern is not about the exact function of the code, but about confirmation that the same code is being used. – schroeder Sep 30 '20 at 11:27
  • 2
    While I agree with the conclusion, I think the argumentation (despite being interesting) got side-tracked. It's far more simple than that: how can the client trust that the server sends the hash of the code it compiled and not just a copy of the expected hash? Whether the binary was compiled correctly or not (i.e. whether it can be trusted) does not matter; this fact does not get into the logical argumentation. – A. Hersean Sep 30 '20 at 11:54
  • 1
    @A.Hersean agree with you. no one can verify it unless having server credentials and verify it yourself. – Tejas Pandya Sep 30 '20 at 12:22
1

If I understand you question correctly, what you are asking is impossible because a server acts like a kind of "black box", and normal users have no way to inspect what is really going on.

You don't simply have to prove that you have something, or that you know something: you would actually need to prove that you use something exactly as expected, including every single step and every single detail of the process. Proving the exact behavior of a black box involves a lot of analysis and inspection that normal users cannot be allowed to do.

In other words, to give a simple example, there is no way that StackExchange can really convince us that they are really storing passwords securely, using a specific implementation of a secure hash function. Some things might help convincing us though: for example, having a continuous and thorough audit system, made by some external trusted authorities. Then, if we can trust the external auditors, we can consider whatever they report to be a proof. Full compliance is however never fully guaranteed (the auditors might be corrupt). As you can see, the issue is pretty complicated.

1

Great question!

This might be not 100% prove, but you may try to get closer with the transparency. What might be done is to allow some level of auditing of the stack. For example to allow publickly see processess(read-only shell?) and which binaries(readonly ftp?) they run. Then, anyone may download the binary, do the checksum and compare with vendor-one.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.