RE: Uploading Patches and Enabling Features in CommercialSystems

Hello All,

Ok so next point:

2) A system must be able to ensure that only the trusted system can ask it
to update itself.

The way that I do this is pretty simple.  If an external system can only say
update, but can not say update from where, then the incentive to break this
message is lessoned.  

You will notice that the next two points make this a circular argument so we
need consider this carefully.

A system could check a server periodically to see if there is an update
available.  If you have a trusted server as in 1) then asking that server
for updates periodically is safe.  

A system could accept messages from the server.  This is very useful for
business production environments.  We need to upgrade all of our clients at
once.  I've solved this problem with a combination of both pushing and
pulling.  First you upload the patch to the server and set the system patch
level that the client checks when it starts up.  This ensures that clients
that are not connected will update when they finally do connect.  Then I
send a message to all running clients to update.  This basically runs the
same code that checks for a patch on start up (and possibly periodically)
but since the message doesn't tell the client where to update from this
message is mostly harmless.  (Although it is important that the message only
be accepted n number of times to prevent DOS attacks).  It is easy to
imagine variations on this process, update when you can, update now, update
after next commit, ask user to update, shutdown if not updated by...

Another variation of this message is a message that says, report home with
your running patch level.  Again it does not accept a location to report
too.  This is very useful for finding dead or disabled clients.

Now I didn't really answer the question of how to determine that only a
trusted system can ask the client to update.  This really depends on your
operating environment.  If you have access to network facilities where the
client is installed then the obvious answer is with a firewall rule.  

If you can not set the network environment then you can fix the problem by
adjusting the message itself.  The first way to do this is to encrypt the
message.  The server can encrypt the message with a random key.  The key
used to encrypt the message should be itself encrypted with the public key
of the client.  Then the client can decrypt the key run an HMAC on the
message and then decrypt it.  Now the public key in this case is not so
public.  The server knows the key of the client, so if the client receives a
message that it can actually read, it can then process the message.  Also
the message is sent on an encrypted SSL connection so it is actually
encrypted twice.  This can be done in the opposite direction, you could have
the server use it's private key to encrypt the random key, and then have the
client decrypt the message with the servers public key.  This reduces the
number of keys needed, but it decreases the security since every message is
readable by every system that knows the servers public key.  It also
increases the traffic on the server's private key which limits its lifetime.


By the way the reason for encrypting a random key using a public key is that
it limits the usefulness of the random key (since it changes with each
message), it keeps the certificate from being used too often so it extends
its life.  We need to add another point, and that is how to update client
and server certificates (see 14 below). 

In summary, 

Make the message safe incase it is received by an unfriendly user.
Limit the communication in a networked environment if possible.
Make the message content authenticate itself, by requiring decryption.
Make the message content verifiable by adding HMAC.

Again your comments are welcome; I received a lot of nice comments about the
last post offline, thank you.  This is a lot of detail so I really want to
make sure you actually find it useful.

Ron Teitelbaum
President / Principal Software Engineer
US Medical Record Specialists
www.usmedrec.com 
Squeak Cryptography Team Leader


> From: Ron Teitelbaum
> 
> Updated List
> 
> 1) A system must be able to ensure that it is updating itself from a
> trusted
> location.  *In Discussion*
> 2) A system must be able to ensure that only the trusted system can ask it
> to update itself.  *In Discussion*
> 3) A system must be able to ensure that it can securely store an update
> location.
> 4) A system must be able to securely change the update location.
> 5) All communications must be encrypted.
> 6) A System must be able to verify patches before applying them.
> 7) A System must be able to automatically load the patch.
> 8) A System should be able to update without restarting the application.
> 9) A System must be able to report back success or failure of patch
> installation.
> 10) A System must be able to recover from a failed patch.
> 11) Security measures have to be spread in many places of the system.
> 12) Security measures should be diverse.
> 13) You have to be very careful not to inconvenience your customers.
  14) A System must be able to update Client and Server Certificates
> 
> The second question is how you can limit functionally in your system
> unless
> and until payment is received.
> 
> 1) A system must be able to enable features for a single instance and
> prevent those features from being shared to other systems.
> 2) A system could be able to detect features being used inappropriately
> 3) A system could be able to periodically check for permission (trial
> software)
>