[Newbies] Uploading Patches and Enabling Features in Commercial Systems

Wed Mar 7 18:07:12 UTC 2007

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.
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.

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)

Herbert,

I agree with your assessment that the topics are applicable to hardware.  
Here are the major differences as I see them.

Hardware encryption is more reliable because the encryption primitives are
encased in a tamper resistant medium.

Hardware encryption is more costly then software.

Hardware performance can be either greater or lower depending on the
implementation.

Hardware to store keys can be very useful if it meets the two factor
authentication: Something you have and something you know.  As long as your
hardware includes a password for authentication to the device, and it allows
only limited password attempts (and the user doesn't write the password on
the device), then a hardware key significantly reduces the vulnerabilities
of authentication.  

Dongles have some issues, they are usually but not always only one factor
(if you have the dongle the system works), they break or can be lost, and
some are easily cracked (so it's important that the value of the software is
less then the amount of work to make your own, or that the dongles be unique
per installation so that the selling of a cracked dongle is not profitable).
Also because the dongle links the computer to the software and not the user
to the software unauthorized users can still access the software.  A good
example is when a user leaves the dongle attached to the computer and goes
to lunch.

I do think that having hardware authentication is a good idea and it does
make things much easier to verify when the crypto code is in the hardware.
I still wonder why it is that they are not more widely used.

As for email, until the certificates are free and the software does all the
work for you, (hardware or not), I doubt we will see much more acceptance.
In the system that I'm building it is all automatic.  If you use my software
and then write an email to your doctor it automatically sends it encrypted
from your regular email program.  Or if you fill out a personalized template
online to communicate with your doctor it is also sent encrypted with your
certificate so that the doctor (and the insurance company) knows they are
talking to the real patient.  

Very good comments! 

Thank you,

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

> From: Herbert König
> Sent: Wednesday, March 07, 2007 12:20 PM
> 
> Hello Ron,
> 
> RT> Nobody updated my list!  I guess this could mean two things either my
> list
> RT> is perfect, or nobody cares.  Please let me know if my comments are
> not
> RT> helpful so that I don't spend too much time on it.
> thanks for going into details, I'm interested but not currently.
> But I read everything you write carefully!
> 
> I'm of the hardware lock fraction mainly because the one I'm using
> offers interesting options in software payment.
> 
> But this is a far in the future plan.
> 
> The things that afaik software locking is bad at are:
> -floating licenses
> -move licenses (for laptop use)
> -stolen keys
> 
> Once you have a hardware lock, you just encrypt every patch you send
> with it and only the owner of the right lock can install it.
> 
> We have about 1000 customers using AutoCAD. They complained about the
> dongle (which was trivial to break) but they really started
> complaining when Adesk introduced soft locking and a software to
> transfer licenses with.
> 
> We use a CA for email in another company. It's just a pain when
> something breaks (certificate expires, the IT person has a belly ache
> and accounting can not send encrypted emails.)
> 
> To any one interested: www.codemeter.com .
> 
> Anyway most of the discussion also is valid for dongle protected
> software so I'm awaiting your next posts.
> 
> Things to add to your list:
> Security measures have to be spread in many places of the system.
> Security measures should be diverse.
> You have to be very careful not to inconvenience (this seems to be a
> word, the spell checker doesn't complain) your customers.
> 
> 
> Herbert                            mailto:herbertkoenig at gmx.net
> 
> _______________________________________________
> Beginners mailing list
> Beginners at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/beginners