RSA blessing - giving a talk
Ray Jones
client/binary verification for network games, using Netrek as a case
study.
It's been a long time since I worked on the blessing scheme (*), so
I'd like some help in preparing a good talk. I think the experiences
of the netrek community could be quite helpful to others. I'm looking
for information, advice, and comments. I want to be accurate and give
credit where due.
I've started an outline of my talk at
http://web.mit.edu/thouis/www/netrek.talk
I'll update it as it morphs into a real talk (of slightly less than an
hour length). Anyone that has something to add, comments, or
suggestions, please mail me. I'll also be reading the group on an
irregular basis.
Ray Jones
[*] Something like not since version 1.0 of the blessing scheme.
Tom Holub
)I'm giving a talk at Rubicon (www.rubi-con.org) about untrusted
)client/binary verification for network games, using Netrek as a case
)study.
)
)It's been a long time since I worked on the blessing scheme (*), so
)I'd like some help in preparing a good talk. I think the experiences
)of the netrek community could be quite helpful to others. I'm looking
)for information, advice, and comments. I want to be accurate and give
)credit where due.
While you're in the neighberhood, are you OK with releasing any of your
code which still exists in the client/server code base under one or all
of the public licensing schemes currently available?
One thing you might want to note is the new UDP_PORTSWAP code, which
basically does away with the random-port call-back of the original
verification scheme. This is a reduction in security, but it's
basically required due to the prevalence of NAT and other firewall-type
things on the net.
You should play test it, of course.
-Tom
Dave Ahn
I was going to send this only over email, but perhaps others might find it
informative.
I assume you're well versed in crypto systems, so I won't reiterate the
obvious. But you did leave out one glaring fact about the netrek
blessed binary scheme: it requires a trusted introducer. Anyway, onward
with my comments...
The fundamental idea of the RES-RSA scheme is tamper-proofing the software
from its user. The most extreme example of this is IBM's crypto module
which provides a self-contained blackbox around encryption software:
http://www-3.ibm.com/security/cryptocards/html/overhardware.shtml
Netrek-on-a-PCI-card anyone?
What's ingenious about RES-RSA isn't the fact that PKC is used for
identification (which is only just clever) but rather that the private
key is publicly distributed in a _functionally_ obfuscated form. The key
itself is never reconstructed during runtime and, therefore, requires
disassembly to recover.
A mathematical analysis of netrek's functional transformer (mkkey) led me
to conclude that it is not one-way. That is, if you trace the value of the
input as it goes through each step of the decryption process, it is possible
to actually recover the private key by doing a bit of backwards math with
the values from each step. I'm not sure if it is possible to create a one-way
functional equivalent without weakening the cipher. I can see some very
interesting directions if it were...
Anyway, given a sufficiently good transform algorithm along with runtime
consistency checks, frequent challenges and binary code obfusation (e.g.
Cloakware), it's possible to create a much more "tamper-proof" netrek client
binary that is difficult to break...certainly beyond the skillset of 99+% of
all gamers out there, perhaps even 99+% of game developers/hackers.
In fact, RES-RSA's mkkey has been sufficiently strong enough that people
have chosen man-in-middle attacks to break the system instead. In today's
gaming environment, RES-RSA won't work by itself. The transport layer
would need to be secured using techniques like ones used in SSH (upper) or
IPSEC (lower). But that poses other major problems for client-server game
systems because of the reliance on UDP and the fact that symmetric ciphers
with persistent keys cannot be used in this scenario. And then there are
all the secondary ways to cheat in games that have nothing to do with
the integrity of the software itself.
Hope this helps.
Dave
> _______________________________________________
> rec.games.netrek mailing list
> rec.game...@us.netrek.org
> https://mailman.real-time.com/mailman/listinfo/rec.games.netrek
--
Dave Ahn | a...@vec.wfubmc.edu | Wake Forest University Baptist Medical Center
When you were born, you cried and the world rejoiced. Try to live your life
so that when you die, you will rejoice and the world will cry. -1/2 jj^2
Dave Ahn
> In article <ppwadxw...@pixie.mit.edu>, Ray Jones <tho...@mit.edu> wrote:
> )I'm giving a talk at Rubicon (www.rubi-con.org) about untrusted
> )client/binary verification for network games, using Netrek as a case
> )study.
> )
> )It's been a long time since I worked on the blessing scheme (*), so
> )I'd like some help in preparing a good talk. I think the experiences
> )of the netrek community could be quite helpful to others. I'm looking
> )for information, advice, and comments. I want to be accurate and give
> )credit where due.
>
> While you're in the neighberhood, are you OK with releasing any of your
> code which still exists in the client/server code base under one or all
> of the public licensing schemes currently available?
Good call.
> One thing you might want to note is the new UDP_PORTSWAP code, which
> basically does away with the random-port call-back of the original
> verification scheme. This is a reduction in security, but it's
> basically required due to the prevalence of NAT and other firewall-type
> things on the net.
I fail to see why it causes an inherent reduction in the security.
The random-port call-back has the same likelihood of being intercepted
and redirected as a client-initiated connection.
Ray Jones
> While you're in the neighberhood, are you OK with releasing any of your
> code which still exists in the client/server code base under one or all
> of the public licensing schemes currently available?
Sure, fine with me. I thought netrek already had a public license, though.
Ray
Tom Holub
)do...@best.com (Tom Holub) writes:
)
)> While you're in the neighberhood, are you OK with releasing any of your
)> code which still exists in the client/server code base under one or all
)> of the public licensing schemes currently available?
)
)Sure, fine with me. I thought netrek already had a public license, though.
It sort of does. The original license, which was written before anything
like the GPL existed, says something like "this code may be used as
long as this copyright notice is maintained, and as long as it's not
for profit". Pedants worry about bundling netrek in commercial products,
like a Linux distribution, for example, with the current language. So
there's been talk of putting it under a more well-understood license
like GPL or Copyleft.
-Tom
Steve Sheldon
"Tom Holub" <do...@best.com> wrote in message
news:f4TG7.3716$Le.9...@sea-read.news.verio.net...
>
> It sort of does. The original license, which was written before anything
> like the GPL existed, says something like "this code may be used as
> long as this copyright notice is maintained, and as long as it's not
> for profit". Pedants worry about bundling netrek in commercial products,
> like a Linux distribution, for example, with the current language. So
> there's been talk of putting it under a more well-understood license
> like GPL or Copyleft.
Or BSD license. Which if you compare to the current netrek license is the
most similar and offers the greater amount of freedom.
Steve Sheldon
"Dave Ahn" <a...@vec.wfubmc.edu> wrote in message
news:mailman.1005300314.6...@us.netrek.org...
>
> The fundamental idea of the RES-RSA scheme is tamper-proofing the software
> from its user. The most extreme example of this is IBM's crypto module
> which provides a self-contained blackbox around encryption software:
> http://www-3.ibm.com/security/cryptocards/html/overhardware.shtml
> Netrek-on-a-PCI-card anyone?
Isn't this the device that was just recently cracked?
http://www.cl.cam.ac.uk/~rnc1/descrack/
> What's ingenious about RES-RSA isn't the fact that PKC is used for
> identification (which is only just clever) but rather that the private
> key is publicly distributed in a _functionally_ obfuscated form. The key
> itself is never reconstructed during runtime and, therefore, requires
> disassembly to recover.
I think it is interesting, because there are many applications where you
need to do cryptography but yet you also want to hide the keys from the
actual user and make it sufficiently difficult for them to extract it.
There are a number of other present applications in which the computer
maintains a private key obfuscated to protect data from users of the app.
For instance Microsoft uses such a private key generated during install to
internally encrypt the Protected Storage area in the OS. This is a part of
the registry in which users private keys are then in turn stored for use in
application level public-key cryptography such as the encrypted file-system,
S/MIME, etc.
Similar techniques are also used with CSS on DVDs, although I believe that's
just a simple shared key algorithm and not PKC. But the key is obfuscated
in the decoder. Or well was supposed to be, when one implemention was
published which didn't properly obfuscate the key, it became public
knowledge. :)
But I thought Ray had some good points on how this effects Netrek.
Fortunately what Netrek is trying to protect is not all that important in
the grand scheme of things. But if a key is compromised there is a very
easy revocation process, and the ability to generate a new key and recompile
the client is quite easy.
> Anyway, given a sufficiently good transform algorithm along with runtime
> consistency checks, frequent challenges and binary code obfusation (e.g.
> Cloakware), it's possible to create a much more "tamper-proof" netrek
client
> binary that is difficult to break...certainly beyond the skillset of 99+%
of
> all gamers out there, perhaps even 99+% of game developers/hackers.
That'd be interesting if you could. There are these other examples I
mentioned and they are somewhat safe, but not really. The job that someone
trying to decrypt the message is made easier by the fact that they have
physical access to whatever is holding the private key, and that what's
holding the private key has to be opened up for use whenever the user runs
the app.
It's a tricky situation, and I can't help but think it's impossible to
achieve 100% protection. If you did have someone who were able to figure
out a way to extract the key, then even if you generated a new key they
could still use the same technique. You'd have to redo your algorithm to
start them back at square 1 in the event of such an occurence.
> In fact, RES-RSA's mkkey has been sufficiently strong enough that people
> have chosen man-in-middle attacks to break the system instead. In today's
Well it is now, I think. The first version didn't use a very random seed
and as a result kept reproducing the same basic set of keys whenever it was
run. :)
Dave Ahn
>
> Isn't this the device that was just recently cracked?
Yeah, I think so. But that's a design flaw...I was pointing out the
general industry approach to hard core tamper-proofing software which
is to stick it in its own isolated environment.
> There are a number of other present applications in which the computer
> maintains a private key obfuscated to protect data from users of the app.
Well, there is a difference between obfuscating the key and obfuscating the
composite of the algorithm and the key. Suppose Microsoft made its
key obfuscation algorithm public. How easy would it be to recover the
key from the obfuscated code? Probably trivial.
> But I thought Ray had some good points on how this effects Netrek.
> Fortunately what Netrek is trying to protect is not all that important in
> the grand scheme of things. But if a key is compromised there is a very
> easy revocation process, and the ability to generate a new key and recompile
> the client is quite easy.
I agree. These benefits are inherent to using PKC for identification
purposes.
> It's a tricky situation, and I can't help but think it's impossible to
> achieve 100% protection. If you did have someone who were able to figure
> out a way to extract the key, then even if you generated a new key they
> could still use the same technique. You'd have to redo your algorithm to
> start them back at square 1 in the event of such an occurence.
You can't achieve 100% protection. But your observation here is fundamental
to the question I posed, which is whether the functional obfuscation is
one way. If it is, then it would be impossible to "break" the obfuscation
algorithm itself and only possible to recover a specific instance of the
obfuscation by brute force. Think of hash algorithms.
Steve Sheldon
> On Fri, Nov 09, 2001 at 10:08:25PM -0600, Steve Sheldon wrote:
> > There are a number of other present applications in which the computer
> > maintains a private key obfuscated to protect data from users of the
app.
>
> Well, there is a difference between obfuscating the key and obfuscating
the
> composite of the algorithm and the key. Suppose Microsoft made its
> key obfuscation algorithm public. How easy would it be to recover the
> key from the obfuscated code? Probably trivial.
Ahh, but we don't know. :)
> > But I thought Ray had some good points on how this effects Netrek.
> > Fortunately what Netrek is trying to protect is not all that important
in
> > the grand scheme of things. But if a key is compromised there is a very
> > easy revocation process, and the ability to generate a new key and
recompile
> > the client is quite easy.
>
> I agree. These benefits are inherent to using PKC for identification
> purposes.
Only if the revocation process is fully implemented. Oddly enough, most PKC
used in web stuff doesn't really have good revocation processes in place.
I'm talking all the verisign keys, etc. The reason being that there's just
so darned many of them.
> > It's a tricky situation, and I can't help but think it's impossible to
> > achieve 100% protection. If you did have someone who were able to
figure
> > out a way to extract the key, then even if you generated a new key they
> > could still use the same technique. You'd have to redo your algorithm
to
> > start them back at square 1 in the event of such an occurence.
>
> You can't achieve 100% protection. But your observation here is
fundamental
> to the question I posed, which is whether the functional obfuscation is
> one way. If it is, then it would be impossible to "break" the obfuscation
> algorithm itself and only possible to recover a specific instance of the
> obfuscation by brute force. Think of hash algorithms.
Interesting point.
Zachary Uram
if it is ever realized.
Zach
zu...@andrew.cmu.edu
"Blessed are those who have not seen and yet have faith." - John 20:29
Darryl Palmer Jr.
listening in on the communication. For a neat introduction, go here:
http://www.qubit.org/intros/crypt.html.
Darryl
"Zachary Uram" <zu...@andrew.cmu.edu> wrote in message
news:mailman.1005443875.7...@us.netrek.org...
Zachary Uram
> _______________________________________________
> rec.games.netrek mailing list
> rec.game...@us.netrek.org
> https://mailman.real-time.com/mailman/listinfo/rec.games.netrek
>
Darryl Palmer Jr.
with the random-port callback? There are still two attacks that are
possible: interception, and infection.
The communication driver can be modified to allow another program to
intercept all TCP/IP calls. This program could then allow certain packets
to go to the original client and other packets to go to a borg client. In
MS Windows this can be done easily be placing custom DLL's in the program
directory or by using the features of MS Windows itself and intercepting all
TCP/IP messages. The program could also be infected with code stored in
either primary or secondary storage to jump to client created routines. Of
the two choices intercepting the calls would probably be the easiest and
will require minimal rewrite of a borg client.
Darryl
P.S. Anyone know where I can get source to a borg? Just kidding, wanted to
piss Tom off. ;)
Dave Ahn
> I was thinking about this today. Isn't the protection still flawed, even
> with the random-port callback? There are still two attacks that are
> possible: interception, and infection.
This is just one example of a man-in-the-middle attack. As I stated before,
RES-RSA verification does not guard against these kinds of attacks.
Zachary Uram
Zach
On Fri, 16 Nov 2001, Darryl Palmer Jr. wrote:
> I was thinking about this today. Isn't the protection still flawed, even
> with the random-port callback? There are still two attacks that are
> possible: interception, and infection.
Darryl Palmer Jr.
get a man in the middle. The first example was leaving the blessed client
alone and rather intercepting communication to it at the API and Operating
Services level. The second one, which I called "infecting the client" was
actually modifying the blessed client. The client could either be modified
in memory or the disk image can be changed. Doing either one would be
highly successful given that someone can compile the public source code and
figure out what the compiled versions of the various functions look like to
decide where to put jump statements to execute code they added at the end of
the image, or they could figure out the memory image of the data rather than
looking at the code. The data could be directly modified to change
behavior. I think it may even be possible to find the key in blessed
clients easily if one can narrow down the RSA packet handler function.
I guess there is another possibility that really isn't man-in-the-middle, it
is more man-on-the-top. With many GUI systems, we can emulate user
keystrokes and mouse-clicks. The only problem is how to convert Netrek's
graphical UI to something that could be sent to another machine. We could
either directly monitor the graphical window, which would be CPU intensive,
or we could just go for intercepting the API calls to the GUI subsystem to
extract information.
So I guess it would be pretty easy to write next-generation borg clients,
that cannot be detected by the verification mechanism in Netrek.
"Zachary Uram" <zu...@andrew.cmu.edu> wrote in message
news:mailman.1005955677.1...@us.netrek.org...
Tom Feng
> I guess they are both man-in-the-middle attacks, the difference is how you
> get a man in the middle. The first example was leaving the blessed client
> alone and rather intercepting communication to it at the API and Operating
> Services level. The second one, which I called "infecting the client" was
> actually modifying the blessed client. The client could either be modified
> in memory or the disk image can be changed. Doing either one would be
> highly successful given that someone can compile the public source code and
> figure out what the compiled versions of the various functions look like to
> decide where to put jump statements to execute code they added at the end of
> the image, or they could figure out the memory image of the data rather than
> looking at the code. The data could be directly modified to change
> behavior. I think it may even be possible to find the key in blessed
> clients easily if one can narrow down the RSA packet handler function.
>
> I guess there is another possibility that really isn't man-in-the-middle, it
> is more man-on-the-top. With many GUI systems, we can emulate user
> keystrokes and mouse-clicks. The only problem is how to convert Netrek's
> graphical UI to something that could be sent to another machine. We could
> either directly monitor the graphical window, which would be CPU intensive,
> or we could just go for intercepting the API calls to the GUI subsystem to
> extract information.
>
> So I guess it would be pretty easy to write next-generation borg clients,
> that cannot be detected by the verification mechanism in Netrek.
I've done both, and yes both are pretty easy to do.
The method netrek currently uses to prevent a simple man-in-the-middle
attack is by the client doing a system call to get the hostname of the
machine it is connected to and using it as part of the identification
message it then encrypts and sends to the server. I simply let my
borg fork and execute a blessed client in debugging mode, trap and
intercept the hostname querying system call, and write into the
client's memory so it thinks it's connected to the server instead of
my borg, and do the RSA verification for me.
The second approach was actually more fun. When I did it about 10
years ago, there was a program written by some people at Brown
University that was an X11 protocol multiplexer (not sure whether it's
still available now, or maybe they have built the functionality into X
servers now). It creates a virtual display :1 on your local machine
and anything drawn onto that display gets drawn simultaneously on
several other machines' displays. It took me only a couple of days to
modify the code to multiplex events back to the virtual display. It's
not a borg, but we had a blast having two or three poeple flying one
starbase. And of course, one could multiplex my borg.
It's a shame that the gradual demise of netrek is not only evident in
the shrinking player base, but also the total non-existance of hackers
and borg writers. I remember CMU once had a clue vs. borg tournament
and clue actually won. Those were the fun times...
Somebody
If you pick up the dynamic client you can
give it false libraries (can't remember the exact one offhand)
and convince it it's connected to a remote server when
infact it's connected to the borg client.
Any time the borg client gets a verification request it passes it to the
trusted client and returns the result.
Is Euro pickup still alive & kicking & are windows clients ok these days?
Don't have my Sun any more :(
Dunk
Niclas Fredriksson
> Is Euro pickup still alive & kicking & are windows clients ok these days?
> Don't have my Sun any more :(
>
> Dunk
Hey Dunk!
There's no pickup in Europe these days, but Euros are playing on
continuum.real-time.com and pickled.psychosis.net. ET is also still
around.
Windows clients are great.
--Niclas