OSDev.org

with following three elements combined it can be super secure, but it will be costly to implement:
- manufacture flash storage device with TPM-like device with ROM memory in which decryption code that are not visible to either user and kernel space is burned onto. Any attempt to look at it will render the flash device useless (self-destruct, tamper proof). Only hardware device i.e. processor itself can access and execute it. Upon execution encrypted code will be fed into TPM-like device which will decrypt the code and give back the program execution to decrypted code.
- encrypt the validation code with private key. the flash device is burned with public key along with decryption code.
- for extra security, decrypted code in memory is also not accessible by any software.

ggodw000 wrote:with following three elements combined it can be super secure, but it will be costly to implement:
- manufacture flash storage device with TPM-like device with ROM memory in which decryption code that are not visible to either user and kernel space is burned onto. Any attempt to look at it will render the flash device useless (self-destruct, tamper proof). Only hardware device i.e. processor itself can access and execute it. Upon execution encrypted code will be fed into TPM-like device which will decrypt the code and give back the program execution to decrypted code.
- encrypt the validation code with private key. the flash device is burned with public key along with decryption code.
- for extra security, decrypted code in memory is also not accessible by any software.

It's already been done... and you have one...

1) TPM Like device with ROM memory
2) encrypt validation code with private key
3) decrypt not accessible by any software

1 is your Intel CPU
2 is an LZW Dictionary in the CPU ROM - encryption == compression https://en.wikipedia.org/wiki/Lempel%E2 ... 80%93Welch
3 is private Intel Management Engine CPU/cache

https://youtu.be/4kCICUPc9_8

https://youtu.be/H6bJ5b8Dgoc

You can in fact get a license from Intel to write apps which run on the Management Engine

cheers

i guess moral of the story, security can not be achieved by software alone. Hardware support is a must.

ggodw000 wrote:i guess moral of the story, security can not be achieved by software alone. Hardware support is a must.

...and then it still cannot be achieved in the ideal, asymptotic sense of "the security".

dozniak wrote:

ggodw000 wrote:i guess moral of the story, security can not be achieved by software alone. Hardware support is a must.

...and then it still cannot be achieved in the ideal, asymptotic sense of "the security".

Largely depends on context, AoV.
Technically, practically or economically?
one can always use brute force technically but considering lifespan of a cracker's age etc., and time to crack using brute force, it can be technically insecure but practically secure.

if considering cost of effort, money involved is not worth the benefit, then economically it is secure.

btw, I am just repeating the author's words of very good crypto book i used to read.

dchapiesky wrote:

dozniak wrote:

ggodw000 wrote:option 1: convoluted code with multiple check points:

if hash1[0:N] == hash2[0:N]
do bunch of other stuff, decompress part of file etc., sheer enough code to discourage disassembly
if hash1[N+1:N+2N] == hash2[N+1:N+2N]
do bunch of other stuff, sheer enough code to discourage further disassembly,
further repeated checks.

option2:
hide validation code by performing simple encryption so that it can not be a disassembled.
during runtime: do a simple decryption so validation code only exist in memory in its unencrypted forum. Of course it is not safe but more work for diassembler.

Do you understand that Skype used option 2 and is now completely fully disassembled once people figured out this logic in the code? It only takes one OCD guy with enough time on his hands.

Do you realize that tools like reverse-analysers can take your convoluted machine code, convert it back to annotated AST representation of assembly code (using symbolic execution) and then reconstruct the entire "obfuscation" logic almost entirely automatically?

I.e. see work from https://www.blackhat.com/docs/eu-16/mat ... oaches.pdf

+1 on what dozniak said.

Intel addresses the issue of option2 by attempting to encrypt the memory transport outside the cpu chip - Intel SGX - however there is still the problem of actually setting up a secure "enclave" as they call it and delivering your secret encrypted code into it so it can be decrypted & executed all while having memory accesses encrypted by SGX.... it is a crap shoot.

Now, if you have enough juice with Intel... you could have them encrypt your code using their LZH dictionary and run your code directly in the Intel Management Unit in every Intel chip since 2010...

https://www.youtube.com/watch?v=0ZVFy4Q ... &index=125