Prev: order discovered in Prime Numbers
Next: An Honest and Simple Question.
From: Clk on 15 Jul 2010 23:14
This is my scenario
- I have an appliance which is installed at customer sites.
The appliance always has internet connectivity. The customers
pay a periodic subscription to use the box.

I want to disable the appliance if the subscription isn't upto date.
So this is what I am planning.

When the appliance is first installed at the customer site, it would
come with a SSL certificate which expires on the date till which his
subscription is paid for.
I would also have a remote server which would have the subscription
details of all my customers. When the customer renews his subscription,
this remote server database would be updated with the new subscription
expiry date.

Everyday, a cron job on the appliance checks the expiry date on the
appliance's
certificate. If the subscription is near expiry, it contacts the remote
server,
checks if the expiry details have changed on the remote server. If it has
changed
send the certificate over the wire to the remote server for renewal & would
get a certificate with the new expiry date.
Past the expiry date on the certificate, the appliance do some action
which would
make it useless for the customer.

Does this sound doable - any gotchas? Any better & tested methods I can use
to achieve this?

I have a webserver running Apache - can I use this same server as my
remote server.
If I do use this as my remote server, is it OK to do this though the
Apache Webserver
itself, or is it better/secure to have a separate program running on a
different port
to serve this subscription needs?
From: robertwessel2 on 16 Jul 2010 03:51
On Jul 15, 10:14 pm, Clk <a...(a)a.org> wrote:
> This is my scenario
> - I have an appliance which is installed at customer sites.
> The appliance always has internet connectivity. The customers
> pay a periodic subscription to use the box.
>
> I want to disable the appliance if the subscription isn't upto date.
> So this is what I am planning.
>
> When the appliance is first installed at the customer site, it would
> come with a SSL certificate which expires on the date till which his
> subscription is paid for.
> I would also have a remote server which would have the subscription
> details of all my customers. When the customer renews his subscription,
> this remote server database would be updated with the new subscription
> expiry date.
>
> Everyday, a cron job on the appliance checks the expiry date on the  
> appliance's
> certificate. If the subscription is near expiry, it contacts the remote  
> server,
> checks if the expiry details have changed on the remote server. If it has  
> changed
> send the certificate over the wire to the remote server for renewal & would
> get a certificate with the new expiry date.
> Past the expiry date on the certificate, the appliance do some action  
> which would
> make it useless for the customer.
>
> Does this sound doable - any gotchas? Any better & tested methods I can use
> to achieve this?
>
> I have a webserver running Apache - can I use this same server as my  
> remote server.
> If I do use this as my remote server, is it OK to do this though the  
> Apache Webserver
> itself, or is it better/secure to have a separate program running on a  
> different port
> to serve this subscription needs?


Ignoring the general distaste for that sort of thing, in basic
outline, that's a fairly common approach. The AV package we use does
just that - the server running it checks for definition updates every
five minutes or so, and also updates the license information at that
time. Many pay one-way broadcast services (satellite radio, for
example), regularly transmit the license keys for all licensed
devices.

The problem is what you're using to time the expiration. Using an SSL
cert's expiration for that would certainly be unusual, if not unique.
Typically you would have an encrypted (and signed) license file that
contained not only the date, but the status of any options (assuming
there are any). Include the device's serial number (or whatever you
use to identify the device in question) in the license file, so that
you can validate that the license belongs to that device
(alternatively hash the devices serial number into the encryption
key).

While it may not apply in your case, something to consider is what
happens when certain types of hardware upgrade occur. For example,
let's say you're using the MAC address on the Ethernet card in the
device as the device's serial number, and the Ethernet car gets
swapped out for some reason. Having the device keel over at that
point is seriously unkind. A grace period is often a good idea, and
not only for that reason. Just because the customer is a bit slow
getting the bill paid is a bad reason to put them out of service - at
the very least the disruption will cause considerable ill will. It's
probably a much better idea to continue to run for (say) 30 days,
while making frequent obnoxious noises through the speaker, or
something else hard to miss.

And, of course, since the device is in possession of the customer, the
license checking code is ultimately hackable.
From: Tom St Denis on 16 Jul 2010 06:25
On Jul 16, 3:51 am, "robertwess...(a)yahoo.com"
<robertwess...(a)yahoo.com> wrote:
> Ignoring the general distaste for that sort of thing, in basic
> outline, that's a fairly common approach.  The AV package we use does
> just that - the server running it checks for definition updates every
> five minutes or so, and also updates the license information at that
> time.  Many pay one-way broadcast services (satellite radio, for
> example), regularly transmit the license keys for all licensed
> devices.

As an XM subscriber (yuk... another story for another day) I know that
they only broadcast your key when you renew or sign-up for about an
hour or so at most. If you miss the window (e.g. radio is off) you
have to either call up or hit the website so they send it again.

I suspect they have something fairly simple based on the timestamp
from the source (they get their clock time from the satellite). Given
my experience with homebrew crypto I bet it's some sort of simple
cipher with an embedded key or something as opposed to something more
rigorous like a proper signature...

Tom
From: robertwessel2 on 16 Jul 2010 06:45
On Jul 16, 5:25 am, Tom St Denis <t...(a)iahu.ca> wrote:
> On Jul 16, 3:51 am, "robertwess...(a)yahoo.com"
>
> <robertwess...(a)yahoo.com> wrote:
> > Ignoring the general distaste for that sort of thing, in basic
> > outline, that's a fairly common approach.  The AV package we use does
> > just that - the server running it checks for definition updates every
> > five minutes or so, and also updates the license information at that
> > time.  Many pay one-way broadcast services (satellite radio, for
> > example), regularly transmit the license keys for all licensed
> > devices.
>
> As an XM subscriber (yuk... another story for another day) I know that
> they only broadcast your key when you renew or sign-up for about an
> hour or so at most.  If you miss the window (e.g. radio is off) you
> have to either call up or hit the website so they send it again.
>
> I suspect they have something fairly simple based on the timestamp
> from the source (they get their clock time from the satellite).  Given
> my experience with homebrew crypto I bet it's some sort of simple
> cipher with an embedded key or something as opposed to something more
> rigorous like a proper signature...


I have XM too, but an hour seems implausibly short. Basically it
would cause almost all automatic renewals to fail (how would you know
when to have the radio turned on?), and that's never happened to me.
Perhaps for a new subscription or a manual renewal, where you can end
the session with a popup that says "turn on the radio in the next 30
minutes and then leave it on for at least 10," it's possible for the
interval to be that short, but for automatic renewals, you'd want at
least a few days.
 | 
Pages: 1
Prev: order discovered in Prime Numbers
Next: An Honest and Simple Question.