Smalltalk › Cincom › VisualWorks

Signing or Verifying the origin of the Parcel files

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

Mark Pirogovsky-3

Signing or Verifying the origin of the Parcel files

Hello All,
I have an interesting question about program security:
in the deployment process we have an options to deploy the applications
via loading parcels at the startup time or maybe applying patches by
loading patches into the single image deployment.

That is all nice and well, but introduces big hole into the security of
the program making it more or less open to any kind of hacking and
reverse engineering.

It there any way to ensure that the parcel came from the authorized
source, by signing it or any other means ?

Any pointers are greatly appreciated

Steven Kelly

RE: Signing or Verifying the origin of the Parcel files

I'd say the easiest way would be to encrypt the parcels, and only expose
your own parcel reading functionality that always decrypts them first.
Parcels can't work on in-memory streams rather than files, but it's
quite easy to add that bit. I've attached some code that does that bit,
and a bit more that you probably don't want. It turns a .pcl file into a
.fix file (actually just a chunk-style Smalltalk file) that when filed
in does the same thing as loading the parcel would. Essentially, it
recreates the parcel file as a byte stream in memory and loads that.

Obviously it's a hack, and only useful for us as it is, but I think
you'll be able to get what you need from this and a quick encryption of
the ByteArray. Drop me a line if you need to.

Steve

> -----Original Message-----
> From: Mark Pirogovsky [mailto:[hidden email]]
> Sent: 24. tammikuuta 2008 21:11
> To: VW NC
> Subject: Signing or Verifying the origin of the Parcel files
>
>
> Hello All,
> I have an interesting question about program security:
> in the deployment process we have an options to deploy the
> applications
> via loading parcels at the startup time or maybe applying patches by
> loading patches into the single image deployment.
>
> That is all nice and well, but introduces big hole into the
> security of
> the program making it more or less open to any kind of hacking and
> reverse engineering.
>
> It there any way to ensure that the parcel came from the authorized
> source, by signing it or any other means ?
>
>
> Any pointers are greatly appreciated
>
>

InternalCodeReader.st (4K) Download Attachment

kobetic

Re: Signing or Verifying the origin of the Parcel files

In reply to this post by Mark Pirogovsky-3

Yes, digital signature is a good way to verify the origin and authenticity of the parcel. I think someone mentioned a while ago on one of the lists that they have support for parcel signing, but nothing like that comes with VW out of the box. The necessary tools are available though, you have both RSA and DSA. Figuring out what exactly should be signed and how to work it into the parcel format is a subtle art though. You probably want to sign not only the bytecode but also some of the parcel properties. You need a scheme how to map the identities of parcel providers to corresponding public keys. You could simply load the image up with a set of trusted keys and try all of them, but it's probably better if the parcel carried an indication of which key should be tried (note, if the parcel carries the key itself, use it only as a key identifier, don't just blindly trust any key that comes with the parcel! The image should only trust the keys it was told to trust!). Embedding an X

509 certificate of the provider is also easy and might be a better scalability story for larger numbers of potential providers that may not all be known upfront. But PKI is known to scare people and can be an overkill for simpler situations.

When we (Cincom) finally get to it, I would like to come up with a solution where key management can be completely customized to whatever is most appropriate for the situation at hand.

HTH,

Martin

Mark Pirogovsky wrote:

> Hello All,
> I have an interesting question about program security:
> in the deployment process we have an options to deploy the applications
> via loading parcels at the startup time or maybe applying patches by
> loading patches into the single image deployment.
>
> That is all nice and well, but introduces big hole into the security of
> the program making it more or less open to any kind of hacking and
> reverse engineering.
>
> It there any way to ensure that the parcel came from the authorized
> source, by signing it or any other means ?
>
>
> Any pointers are greatly appreciated
>
>

kobetic

Re: Signing or Verifying the origin of the Parcel files

In reply to this post by Steven Kelly

Thanks for the InternalCodeReader, Steven, I filed it with the AR that we have for this issue.

Just wanted to note that in general case, encryption is not supposed to be used for authentication (of either origin or content). Unless used in a special mode that provides those features, encryption doesn't necessarily give an indication if the content was modified or wasn't encrypted with the key you're using to decrypt. While it will likely yield garbage and you will probably detect malformed content later on somehow, it's just not the way to go. With security it generally doesn't matter that it works in 99.9% cases, what matters are the cases where it doesn't and how hard it is to exploit those. So, if you want authentication, you want to use signing.

Martin

Steven Kelly wrote:

> I'd say the easiest way would be to encrypt the parcels, and only expose
> your own parcel reading functionality that always decrypts them first.
> Parcels can't work on in-memory streams rather than files, but it's
> quite easy to add that bit. I've attached some code that does that bit,
> and a bit more that you probably don't want. It turns a .pcl file into a
> .fix file (actually just a chunk-style Smalltalk file) that when filed
> in does the same thing as loading the parcel would. Essentially, it
> recreates the parcel file as a byte stream in memory and loads that.
>
> Obviously it's a hack, and only useful for us as it is, but I think
> you'll be able to get what you need from this and a quick encryption of
> the ByteArray. Drop me a line if you need to.
>
> Steve
>
>> -----Original Message-----
>> From: Mark Pirogovsky [mailto:[hidden email]]
>> Sent: 24. tammikuuta 2008 21:11
>> To: VW NC
>> Subject: Signing or Verifying the origin of the Parcel files
>>
>>
>> Hello All,
>> I have an interesting question about program security:
>> in the deployment process we have an options to deploy the
>> applications
>> via loading parcels at the startup time or maybe applying patches by
>> loading patches into the single image deployment.
>>
>> That is all nice and well, but introduces big hole into the
>> security of
>> the program making it more or less open to any kind of hacking and
>> reverse engineering.
>>
>> It there any way to ensure that the parcel came from the authorized
>> source, by signing it or any other means ?
>>
>>
>> Any pointers are greatly appreciated
>>
>>

Andre Schnoor

Re: Signing or Verifying the origin of the Parcel files

In reply to this post by Steven Kelly

Steven Kelly schrieb:
> Parcels can't work on in-memory streams rather than files, but it's
> quite easy to add that bit.
IIRC from the top of my head now, with a litte tweaking of CodeReader,
they can. CodeReader (if I remember the class name correctly) must be
changed to be able to load code from any stream, which is possible.

I'm current away from my office, but will have a look into this when I'm
back.

Andre

Steven Kelly

RE: Signing or Verifying the origin of the Parcel files

In reply to this post by Mark Pirogovsky-3

Martin's absolutely right: I wrote "encryption" when I really meant
"encryption and signing" or at least "encryption and checksum". Mark
needs the encryption, since part of his purpose is to prevent people
reverse engineering his image - and presumably also the bits supplied in
the parcel.

To my naive way of thinking, the signing or checksum is more just to
prevent errors that could occur when attempting to read the garbage that
will result from decrypting something that wasn't encrypted correctly.
There's no real additional security that I can think of: if someone can
get hold of your encyption key, they can get hold of your signing key.
(Talking in the most general sense, rather than about a particular
cryptographical algorithm or infrastructure.)

Of course Smalltalk images aren't encrypted, but Smalltalk is a rare
enough language, and most Smalltalk apps are in a small enough niche,
that this probably doesn't matter much in practice. The number of people
who can already hack the code out of an RTP'd VW image is probably only
10-20, and those who could relatively easily figure out how to do it is
probably still only in double figures.

"Security by obscurity" is criticized more than it should be, IMHO. All
digital security is based on the fact that nobody initially knows how to
decrypt, and it's a lot of work to find out how to. Whether you're
finding out an algorithm, a large number, or how a language stores its
bytecode, it's all pretty much the same. What matters is who can do it,
how long it takes, and what resources it requires. The best way to break
most of today's cryptography is to attack the human element. Even if
Mark encrypts his image, it's no huge task to break into his home or
office and walk off with his computers: the source will be there
somewhere, unencrypted. And there are a lot more people who know how to
break a window than have PhDs in elliptic curve cryptography.

Cheers,
Steve

> -----Original Message-----
> From: Martin Kobetic [mailto:[hidden email]]
> Sent: 25. tammikuuta 2008 0:43
> To: Steven Kelly
> Cc: Mark Pirogovsky; VW NC
> Subject: Re: Signing or Verifying the origin of the Parcel files
>
>
> Thanks for the InternalCodeReader, Steven, I filed it with
> the AR that we have for this issue.
>
> Just wanted to note that in general case, encryption is not
> supposed to be used for authentication (of either origin or
> content). Unless used in a special mode that provides those
> features, encryption doesn't necessarily give an indication
> if the content was modified or wasn't encrypted with the key
> you're using to decrypt. While it will likely yield garbage
> and you will probably detect malformed content later on
> somehow, it's just not the way to go. With security it
> generally doesn't matter that it works in 99.9% cases, what
> matters are the cases where it doesn't and how hard it is to
> exploit those. So, if you want authentication, you want to
> use signing.
>
> Martin
>
> Steven Kelly wrote:
> > I'd say the easiest way would be to encrypt the parcels, and only
> > expose your own parcel reading functionality that always
> decrypts them
> > first. Parcels can't work on in-memory streams rather than
> files, but
> > it's quite easy to add that bit. I've attached some code that does
> > that bit, and a bit more that you probably don't want. It
> turns a .pcl
> > file into a .fix file (actually just a chunk-style Smalltalk file)
> > that when filed in does the same thing as loading the parcel would.
> > Essentially, it recreates the parcel file as a byte stream
> in memory
> > and loads that.
> >
> > Obviously it's a hack, and only useful for us as it is, but I think
> > you'll be able to get what you need from this and a quick
> encryption
> > of the ByteArray. Drop me a line if you need to.
> >
> > Steve
> >
> >> -----Original Message-----
> >> From: Mark Pirogovsky [mailto:[hidden email]]
> >> Sent: 24. tammikuuta 2008 21:11
> >> To: VW NC
> >> Subject: Signing or Verifying the origin of the Parcel files
> >>
> >>
> >> Hello All,
> >> I have an interesting question about program security:
> >> in the deployment process we have an options to deploy the
> >> applications
> >> via loading parcels at the startup time or maybe applying
> patches by
> >> loading patches into the single image deployment.
> >>
> >> That is all nice and well, but introduces big hole into the
> >> security of
> >> the program making it more or less open to any kind of hacking and
> >> reverse engineering.
> >>
> >> It there any way to ensure that the parcel came from the
> authorized
> >> source, by signing it or any other means ?
> >>
> >>
> >> Any pointers are greatly appreciated
> >>
> >>
>
>

Steven Kelly

RE: Signing or Verifying the origin of the Parcel files

In reply to this post by Mark Pirogovsky-3

From: [hidden email] [mailto:[hidden email]]
> Steven Kelly schrieb:
> > Parcels can't work on in-memory streams rather than files, but it's
> > quite easy to add that bit.
> IIRC from the top of my head now, with a litte tweaking of
> CodeReader,
> they can. CodeReader (if I remember the class name correctly) must be
> changed to be able to load code from any stream, which is possible.

That's what InternalCodeReader does. The instance side method takes care
of that; the class side methods show how to use it.

I'm sure Andre's stuff goes a lot further: we only use ours to be able
to supply DLLCC source code to images without DLLCC loaded.

Steve

kobetic

Re: Signing or Verifying the origin of the Parcel files

In reply to this post by Steven Kelly

Steven Kelly wrote:
> To my naive way of thinking, the signing or checksum is more just to
> prevent errors that could occur when attempting to read the garbage that
> will result from decrypting something that wasn't encrypted correctly.
> There's no real additional security that I can think of: if someone can
> get hold of your encyption key, they can get hold of your signing key.
> (Talking in the most general sense, rather than about a particular
> cryptographical algorithm or infrastructure.)

Well, yes, once the key is compromised, all bets are off. However, there is a big difference in how hard it is to keep the key secret. With symmetric key algorithms (where both the sender and receiver need the same key), you need a different key for each sender/receiver pair. With asymmetric (public) key algorithms only the producer knows the private key, and the public key doesn't need to be secret at all. That's much easier to manage. The producer can keep the private key locked up, there's no valid reason to reveal it to anybody.

I'd actually argue that authentication is the most interesting benefit you can get from cryptography wrt to code. If you have a digital signature and it checks out, you can be quite certain that the signature was generated with the corresponding private key. I think that's very significant benefit for fairly low cost. And it eliminates majority of attack sources. It doesn't help you if you're being attacked through the provider, but it's the difference of having to fend off attacks from anywhere and being able to focus on just this small entrance over there.

I'd say that it's the encryption for the purpose of keeping your code secret that is futile. The code has to be decrypted to run, and usually it has to run on machines of your clients that you have no control over. That's pretty difficult situation and the incentives are all set up against the provider. The client, on who's machines the code runs, has nothing to gain from keeping the code secret. As opposed to code authentication where there are clear benefits. In the end it's all about the cost to attack, cost to defend, and the value that can be extracted, for some very fuzzy definition of 'cost' and 'value' of course :-).

Cheers,

Martin

Mark Pirogovsky-3

Re: Signing or Verifying the origin of the Parcel files

Ok,
That is very lively discussion and I agree with all the points of view,
however in practical terms what I need is to make sure that my
application will not load smalltalk parcel from unknown source. And it
does not matter what I am using - encryption or signatures, as long as I
have something going... Right now I need to figure out how to sign or
encrypt the parcel in a tamper proof way... something similar to the
executable signing.

Martin Kobetic wrote:

> Steven Kelly wrote:
>> To my naive way of thinking, the signing or checksum is more just to
>> prevent errors that could occur when attempting to read the garbage that
>> will result from decrypting something that wasn't encrypted correctly.
>> There's no real additional security that I can think of: if someone can
>> get hold of your encyption key, they can get hold of your signing key.
>> (Talking in the most general sense, rather than about a particular
>> cryptographical algorithm or infrastructure.)
>
> Well, yes, once the key is compromised, all bets are off. However, there
> is a big difference in how hard it is to keep the key secret. With
> symmetric key algorithms (where both the sender and receiver need the
> same key), you need a different key for each sender/receiver pair. With
> asymmetric (public) key algorithms only the producer knows the private
> key, and the public key doesn't need to be secret at all. That's much
> easier to manage. The producer can keep the private key locked up,
> there's no valid reason to reveal it to anybody.
>
> I'd actually argue that authentication is the most interesting benefit
> you can get from cryptography wrt to code. If you have a digital
> signature and it checks out, you can be quite certain that the signature
> was generated with the corresponding private key. I think that's very
> significant benefit for fairly low cost. And it eliminates majority of
> attack sources. It doesn't help you if you're being attacked through the
> provider, but it's the difference of having to fend off attacks from
> anywhere and being able to focus on just this small entrance over there.
>
> I'd say that it's the encryption for the purpose of keeping your code
> secret that is futile. The code has to be decrypted to run, and usually
> it has to run on machines of your clients that you have no control over.
> That's pretty difficult situation and the incentives are all set up
> against the provider. The client, on who's machines the code runs, has
> nothing to gain from keeping the code secret. As opposed to code
> authentication where there are clear benefits. In the end it's all about
> the cost to attack, cost to defend, and the value that can be extracted,
> for some very fuzzy definition of 'cost' and 'value' of course :-).
>
> Cheers,
>
> Martin
>
>
>