OSDev.org

The Place to Start for Operating System Developers
It is currently Sat Nov 18, 2017 4:20 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 36 posts ]  Go to page Previous  1, 2, 3
Author Message
 Post subject: Re: Idea for copy protect
PostPosted: Fri Jan 13, 2017 12:52 am 
Offline
Member
Member

Joined: Wed Nov 18, 2015 3:04 pm
Posts: 284
Location: San Jose San Francisco Bay Area
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.

_________________
key takeaway after spending yrs on sw industry: big issue small because everyone jumps on it and fixes it. small issue is big since everyone ignores and it causes catastrophy later. #devilisinthedetails


Top
 Profile  
 
 Post subject: Re: Idea for copy protect
PostPosted: Fri Jan 13, 2017 2:28 am 
Offline
Member
Member
User avatar

Joined: Sun Dec 25, 2016 1:54 am
Posts: 204
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

_________________
Plagiarize. Plagiarize. Let not one line escape thine eyes...


Top
 Profile  
 
 Post subject: Re: Idea for copy protect
PostPosted: Fri Jan 13, 2017 5:14 pm 
Offline
Member
Member

Joined: Wed Nov 18, 2015 3:04 pm
Posts: 284
Location: San Jose San Francisco Bay Area
i guess moral of the story, security can not be achieved by software alone. Hardware support is a must.

_________________
key takeaway after spending yrs on sw industry: big issue small because everyone jumps on it and fixes it. small issue is big since everyone ignores and it causes catastrophy later. #devilisinthedetails


Top
 Profile  
 
 Post subject: Re: Idea for copy protect
PostPosted: Fri Jan 13, 2017 5:51 pm 
Offline
Member
Member
User avatar

Joined: Thu Jul 12, 2012 7:29 am
Posts: 718
Location: Tallinn, Estonia
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".

_________________
Learn to read.


Top
 Profile  
 
 Post subject: Re: Idea for copy protect
PostPosted: Fri Jan 13, 2017 6:25 pm 
Offline
Member
Member

Joined: Wed Nov 18, 2015 3:04 pm
Posts: 284
Location: San Jose San Francisco Bay Area
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. :o

_________________
key takeaway after spending yrs on sw industry: big issue small because everyone jumps on it and fixes it. small issue is big since everyone ignores and it causes catastrophy later. #devilisinthedetails


Top
 Profile  
 
 Post subject: Re: Idea for copy protect
PostPosted: Fri Jan 13, 2017 9:56 pm 
Offline
Member
Member

Joined: Wed Nov 18, 2015 3:04 pm
Posts: 284
Location: San Jose San Francisco Bay Area
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

_________________
key takeaway after spending yrs on sw industry: big issue small because everyone jumps on it and fixes it. small issue is big since everyone ignores and it causes catastrophy later. #devilisinthedetails


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 36 posts ]  Go to page Previous  1, 2, 3

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group