This was in a different thread, but it's taking a new direction, so I'll
start a new thread... (sorry!)
Background -- a security license check needs to be done for an add-on
module we're developing for an application (which has KCL as its extension
language). we want to protect the keys for the licensing system (the keys
are the args to a function call that accesses the license machine). Macros
looked good, as they expand inline, but we want others to be able to use our
"more secure" licensing scheme without exposing what we're doing (and
"macroexpand" will allow the others to see what our macro is doing). So,
picking up midstream....
> > Any other thoughts on how to protect this code?
>
> Ultimately, you can't. You can only make it hard to reverse
> engineer. You might be able to make it so hard to reverse engineer
> that no one would bother.
Ok, so here's an (ugly) idea that I think might do the trick (though I would
most likely need some help with implementation):
known issues:
1) the security system definitely needs an overhaul since the keys
themselves are vulnerable (but I can't control this partince our application
is an add-in module for another application)
2) I want to protect the code that I developed to do the license checking.
3) the keys need to be protected.
So, what if I had a macro that the user could link into their code that did
something like this:
1) create a global variable
2) stick the keys into this global variable (preferably encrypted -- how do
I do this?)
3) call a separate (compiled) mylicense function that does all the license
checking
(most likely with dummy parameters to fool traces)
4) read the function result, either from the return value or from another
global var created by the function (or both)
5) unbind the global var from the mylicense function
then the separate mylicense function would do similar things as above:
1) read the info from the global var (and decrypt if necessary)
2) unbind the global var from the above macro (this way the global var is
only in existence for a very short time)
3) do the license check
4) create a new global var
5) stick a set of results (more than just the expected result) into the
global var (to help check for someone redefining the mylicense function)
6) return some value to the calling macro
This approach should allow me to keep the license-checking methodology
buried in the compiled function (i.e we don't expose anything), and to pass
parameters back and forth in a (hopefully) more difficult-to-trace manner.
(esp. if I can dynamically assign the names of the global variables, perhaps
using time-coding or something).
Any thoughts on whether this would work (and how well)? Other suggestions?
thanks,
bufie
In article <························@attbi_s03>,
"bufie" <·····@spamneggs.com> wrote:
> Any thoughts on whether this would work (and how well)?
Joe Marshall did a pretty good job of pointing out the problems in your
design. But I'd like to make a larger point: it's pretty clear that you
don't understand much about computer security, and until you do it
essentially impossible for you to design a secure system. Even people
who really ought to know better often can't get it right. See for
example:
http://www.windowsxpuser.com/forums/viewtopic.php?p=17693
> Other suggestions?
I'd start by reading Bruce Schneier's "Applied Cryptography."
(Actually, it's not a bad idea to read everything that Bruce Schneier
has ever written.) Then read all the comp.risks archives.
As Joe said, computer security is hard. Really really hard. (And
designing a system that is secure against dishonest insiders is really
really really hard!) There are no shortcuts. (That includes, by the
way, hiring self-styled "security experts" because they often don't know
what they're talking about either.)
E.
From: bufie
Subject: Re: Macros and temporary global vars (was make macro unexpandable)
Date:
Message-ID: <q27rc.12860$zw.878@attbi_s01>
Thanks for the comments and suggestions.
> > Any thoughts on whether this would work (and how well)?
>
> Joe Marshall did a pretty good job of pointing out the problems in your
> design. But I'd like to make a larger point: it's pretty clear that you
> don't understand much about computer security,
how did you guess? :) you are right -- I don't know much about
computer security, and the whole point of this is just to make a very
insecure
system somewhat less insecure... :) The system we're adding on to has all
the holes, and we're just tring to make it hold a little more water...
> and until you do it
> essentially impossible for you to design a secure system. Even people
> who really ought to know better often can't get it right. See for
> example:
>
> http://www.windowsxpuser.com/forums/viewtopic.php?p=17693
always scary when the "experts" don't get it right!
> > Other suggestions?
>
> I'd start by reading Bruce Schneier's "Applied Cryptography."
> (Actually, it's not a bad idea to read everything that Bruce Schneier
> has ever written.) Then read all the comp.risks archives.
>
> As Joe said, computer security is hard. Really really hard. (And
> designing a system that is secure against dishonest insiders is really
> really really hard!) There are no shortcuts. (That includes, by the
> way, hiring self-styled "security experts" because they often don't know
> what they're talking about either.)
Thanks again for your comments. I'll give it a look.
bufie
From: David Steuber
Subject: Re: Macros and temporary global vars (was make macro unexpandable)
Date:
Message-ID: <87r7tefkzd.fsf@david-steuber.com>
Erann Gat <·········@flownet.com> writes:
> I'd start by reading Bruce Schneier's "Applied Cryptography."
> (Actually, it's not a bad idea to read everything that Bruce Schneier
> has ever written.) Then read all the comp.risks archives.
It's in it's second edition now. I think it is perhaps the scariest
book I have ever read. Certainly I would consider it required reading
for anyone interested in cryptography.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
From: Joe Marshall
Subject: Re: Macros and temporary global vars
Date:
Message-ID: <7jv5fxub.fsf@ccs.neu.edu>
David Steuber <·····@david-steuber.com> writes:
> Erann Gat <·········@flownet.com> writes:
>
>> I'd start by reading Bruce Schneier's "Applied Cryptography."
>> (Actually, it's not a bad idea to read everything that Bruce Schneier
>> has ever written.) Then read all the comp.risks archives.
>
> It's in it's second edition now. I think it is perhaps the scariest
> book I have ever read.
Try `The Hot Zone' by Richard Preston.
Imagine a newly discovered filovirus that causes hemorrhaghic fever.
Like Ebola, it kills about 50% of those infected within days. There
is no treatment.
Unlike Ebola, it is easily transmitted through the air.
Unlike Ebola, it is discovered in a major metropolitan area: the
suburbs of Washington DC.
Very fortunately for us, this variant of Ebola virus is the only one
which doesn't seem to be the least bit dangerous to people. Several
people were infected, but none got ill.
This is a scary book.
David Steuber <·····@david-steuber.com> wrote in message news:<··············@david-steuber.com>...
> Erann Gat <·········@flownet.com> writes:
>
> > I'd start by reading Bruce Schneier's "Applied Cryptography."
> > (Actually, it's not a bad idea to read everything that Bruce Schneier
> > has ever written.) Then read all the comp.risks archives.
>
> It's in it's second edition now. I think it is perhaps the scariest
> book I have ever read. Certainly I would consider it required reading
> for anyone interested in cryptography.
Scariest? Please expand. I'm not familiar with the book, but I don't
see how a book on cryptography could be scary in any way, other than
perhaps showing methods of breaking cryptography that could be applied
by "Big Brother" or something.
Chris Capel
From: David Steuber
Subject: Re: Macros and temporary global vars (was make macro unexpandable)
Date:
Message-ID: <877jv5hvsx.fsf@david-steuber.com>
·····@ibanktech.net (Chris C apel) writes:
> David Steuber <·····@david-steuber.com> wrote in message news:<··············@david-steuber.com>...
> > Erann Gat <·········@flownet.com> writes:
> >
> > > I'd start by reading Bruce Schneier's "Applied Cryptography."
> > > (Actually, it's not a bad idea to read everything that Bruce Schneier
> > > has ever written.) Then read all the comp.risks archives.
> >
> > It's in it's second edition now. I think it is perhaps the scariest
> > book I have ever read. Certainly I would consider it required reading
> > for anyone interested in cryptography.
>
> Scariest? Please expand. I'm not familiar with the book, but I don't
> see how a book on cryptography could be scary in any way, other than
> perhaps showing methods of breaking cryptography that could be applied
> by "Big Brother" or something.
It deals with very big numbers. Anything that requires more than all
my fingers to count is inherently intimidating.
It's actually rather difficult for me to explain. The secret is in
the keys. The book is worth becoming familiar with. It is quite well
written. Although if you are in the field, it might all be old hat to
you. In any event, what would it mean if all key based encryption
systems broke down because there was a way to derive the key by means
other than brute force? IOW, the only secure encryption would be that
done with a one time pad.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
From: Joe Marshall
Subject: Re: Macros and temporary global vars
Date:
Message-ID: <aczxesny.fsf@ccs.neu.edu>
David Steuber <·····@david-steuber.com> writes:
> It [Applied Cryptography] deals with very big numbers.
Nah, the numbers can easily fit on a page. *Very* big numbers are
things like the length of a Goodstein sequence or the number of steps
taken by a busy beaver turing machine.
> Anything that requires more than all my fingers to count is
> inherently intimidating.
Good mathematicians go barefoot.
> In any event, what would it mean if all key based encryption
> systems broke down because there was a way to derive the key by means
> other than brute force?
It would mean, among other things, that P=NP. (I believe that there
are cryptosystems that are based on np-complete problems.)
> IOW, the only secure encryption would be that done with a one time
> pad.
That *is* the only encryption where a sufficient amount of cyphertext
cannot be decrypted given a sufficient amount of time. But that is a
limiting case. You rarely need secrets to last forever and you only
need to make it harder to decrypt than to get the secret through other
means.
Joe Marshall wrote:
> David Steuber <·····@david-steuber.com> writes:
>
>
>>It [Applied Cryptography] deals with very big numbers.
>
>
> Nah, the numbers can easily fit on a page. *Very* big numbers are
> things like the length of a Goodstein sequence or the number of steps
> taken by a busy beaver turing machine.
>
>
>>Anything that requires more than all my fingers to count is
>>inherently intimidating.
>
>
> Good mathematicians go barefoot.
And hillbilly mathemeticians use strange number bases, like 11 or 19.
>>IOW, the only secure encryption would be that done with a one time
>>pad.
>
>
> That *is* the only encryption where a sufficient amount of cyphertext
> cannot be decrypted given a sufficient amount of time. But that is a
> limiting case. You rarely need secrets to last forever and you only
> need to make it harder to decrypt than to get the secret through other
> means.
A good rule of thumb is to never make your encryption take more effort
to break than it would take to torture you for the information you're
encrypting. ;)
Erann Gat <·········@flownet.com> wrote:
+---------------
| > Other suggestions?
|
| I'd start by reading Bruce Schneier's "Applied Cryptography."
| (Actually, it's not a bad idea to read everything that Bruce Schneier
| has ever written.)
+---------------
Given the OP's level of (non-)experience with security, I'd suggest
Schneier's "Secrets & Lies: Digital Security in a Networked World"
<URL:http://www.schneier.com/book-sandl.html> as being a better book to
read first.
+---------------
| Then read all the comp.risks archives.
+---------------
Yup. They're easy to read at <URL:http://catless.ncl.ac.uk/Risks/>.
Also read the sci.crypt newsgroup...
+---------------
| As Joe said, computer security is hard. Really really hard. (And
| designing a system that is secure against dishonest insiders is really
| really really hard!) There are no shortcuts. (That includes, by the
| way, hiring self-styled "security experts" because they often don't know
| what they're talking about either.)
+---------------
I would 2nd, 3rd, and 4th this!!
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Eric Blood
Subject: Re: Macros and temporary global vars (was make macro unexpandable)
Date:
Message-ID: <c93gs501qk1@news3.newsguy.com>
Erann Gat wrote:
> I'd start by reading Bruce Schneier's "Applied Cryptography."
> (Actually, it's not a bad idea to read everything that Bruce Schneier
> has ever written.) Then read all the comp.risks archives.
I would more recommend Practical Cryptography by Ferguson and Schneier.
Instead of focusing on a wide-range of algorithms, it provides some
guidelines on how to choose the proper algorithm, how to approach the
protocol, etc. It also gives a good dose of *securit is hard* and
ancetdotes.
--
eblood
From: Joe Marshall
Subject: Re: Macros and temporary global vars
Date:
Message-ID: <3c5vgjpa.fsf@ccs.neu.edu>
"bufie" <·····@spamneggs.com> writes:
> Background -- a security license check needs to be done for an add-on
> module we're developing for an application (which has KCL as its extension
> language). we want to protect the keys for the licensing system (the keys
> are the args to a function call that accesses the license machine). Macros
> looked good, as they expand inline, but we want others to be able to use our
> "more secure" licensing scheme without exposing what we're doing (and
> "macroexpand" will allow the others to see what our macro is doing).
I used to work for a small company that made an inexpensive mobile
data terminal system. Basically, we put laptops in police cars and
ambulances and used their existing radio channel to communicate to the
base. It was attractive to small towns because it didn't require an
upgrade to their entire system, and it didn't need a dedicated radio
channel (the federal government charges the police department a fair
amount of money to license the frequency and some towns can't budget
it).
It was very important for me to feel confident that this sort of
system could not be abused by the local PDs or by unscrupulous
officers. (I was surprised to find that *many* of the police chiefs
expressed concern about this as well! One of our selling points
was that we kept secure audit trails of all digital communications and
that this would be expensive to add to the legacy audio channel.
Also, it is easy to ask the dispatcher at the station to bend the
rules a bit (or a lot. This happens far too regularly), but if the
digital system doesn't implement questionable commands, there isn't
much way around it.)
Obviously it is vital to have very good security. We worked from the
conservative assumption that a corrupt police officer would at *least*
have unlimited access to the remote terminals and that he would
actively attempt to bypass security, alter audit trails, inject false
data, and compromise the base unit in order to open an avenue of
attack to the state and federal systems. It is paranoid, but there
are associated benefits with making these assumptions. Among them is
secure licensing (if we can keep an unauthorized officer from hacking
the system we could surely ensure that the license was up to date!)
Unfortunately, the original implementor of the system had little
experience with practical security. The communications between the
client and the base were securely encrypted, and this offers a small
measure of authentication, but the keys were embedded in the source
code! The original implementor wrote a script to generate
pseudorandom keys into a header file which was used to build the
system. The communication channel was quite secure: it would take a
long, long time and a lot of computer power to figure out what key was
used to encrypt a packet, but since the key was right in the source
code, it would take microseconds to simply try every contiguous 8-byte
chunk of the executable image. Despite the effort of encryption,
there was no real security whatsoever.
The suggestion hiding the keys in a macro is analagous. It would be
trivial to scan the heap image to extract possible keys (even more
trivial than scanning a C executable because the heap has type codes
to make it easy to parse.)
You can only make the system hard to reverse engineer. With enough
work you may be able to make it so hard to reverse engineer that no
one would bother. Hiding the keys this way, however, just makes it
harder for *you*.
> Ok, so here's an (ugly) idea that I think might do the trick (though I would
> most likely need some help with implementation):
>
> known issues:
> 1) the security system definitely needs an overhaul since the keys
> themselves are vulnerable (but I can't control this part since our application
> is an add-in module for another application)
> 2) I want to protect the code that I developed to do the license checking.
> 3) the keys need to be protected.
The only way to protect the key is to not hand it out in the first
place. The reason there *are* keys is that they are smaller and
easier to manage than the entire system.
You need to rethink your known issues. I suggest starting with these:
1. The software is intended to run on an untrusted machine and is
linked to an untrusted application.
2. Yet you wish to restrict the use of your software to only those
that have a purchased a license to it.
From this starting point the conclusion is `you're screwed'. 100%
totally and absolutely screwed. Here's why. The software (not being
omniscient) does know if the user has a license. (You make this
assumption in your issue number 2. If the software knew whether the
user had a license or not, it wouldn't need to check.) The software
therefore has to ask about the existance of the license. The software
can only communicate with the surrounding application and the OS,
either of which could be hostile. If the software has to ask a
question and if it has to assume that any or all answers could be
lies, why bother asking?
[complex suggestion elided]
>
> Any thoughts on whether this would work (and how well)? Other
> suggestions?
>
The `man-in-the-middle' attack works against this every time. I write
a shim module that pretends to be the license checker to the
application and pretends to be the application to the license
checker. Every time the license is checked, your code asks my shim.
My shim asks the license checker. The answer comes back via the
shim. Now even if you use a `back channel' (like a hidden symbol) for
communicating between the two parts, the channel must remain open
between when the license checker transmits the answer `yes' and the
application receives the `yes', and my shim code will run while that
channel is open.
I put my shim in place and I'm ready to go. Just before I call one of
your functions, I take a snapshot of memory. As soon as my shim gets
control, I take another. Now I `diff' the two snapshots.
Another way: I run software on a nested emulator like VMWARE. I
arrange for VMWARE to halt upon entry to the license checking code.
Now I just single step and see what memory location the license
checking code is reading from and writing to.
You might object that `no one would do that', but go to any warez
site. There are automated tools that can do what I just suggested, so
it isn't as if there is a huge time and energy investment here.
True security is *hard*. If you really need to ensure the security of
your software you need trusted hardware somewhere in the loop. The
most secure way is to keep your software in house and run it as a
network service with some sort of Kerberos-like security system
holding the keys (well, even more secure is to never run the software,
but that's usually not an option). Less secure is to use a dongle or
smart card. License files and software validation or some such can
deter honest people but cannot stop a determined opponent.
The best plan is to stop thinking about clever macros and invest that
energy in making the software worth stealing!