Re: Webcall.ca cookbook (and concerns)

On 14-Dec-06, at 3:05 AM, Dylan Griffiths wrote:

> Tony Arkles wrote:
>> How do you propose to do this without human intervention?
>
> The same way Microsoft turns blank Xbox 360s into keyed Xbox 360s.
> Either the boxes have enough juice to generate their own pairs, or
> you have a machine on a step of the assembly line before they go
> out the door that generates a pair, sticks it in the db, and burns
> the private key onto the board's EEPROM, along with Sasktel's
> pubkey and any other data.

Right. Except in this case, Sasktel doesn't own the assembly line.
It's also in their best interest to be able to use standard hardware,
instead of requiring custom bits (e.g. getting their specific private
key burned into an EEPROM at the factory). This way, whenever they
need more units, they don't have the lead time of having their
manufacturer retool.

Although considering it further, I'm not even sure if Sasktel's pub
key is necessary. If Sasktel is the only entity that has a copy of
the box's public key, then it's not really a big deal to have two
sets of pub/priv key pairs.

>
>> That public key has to get associated with the specific telephone
>> number, correct? Either someone is going to have to copy the key
>> from
>
> No, it's associated with the box. The box has a UUID (the Mac)
> already. If you have a nice db of public keys and Macs for them at
> Sasktel HO, and each box has its own Mac + priv key + Sasktel's pub
> key, that's most of the problem right there.
>
> Associating it with the telephone number means you'd have to rekey
> a box everytime you changed accounts, #s, etc, which is obviously
> not useful.
>
>> I agree that the system as it is probably could use improvement.
>> From my "life as a DSL installer" days though, I see this being
>> way more of a pain-in-the-ass than simply making sure a set of
>> keys are correct.
>
> It'd already be fine at that point.
>
> The pub/priv key pairs are only to ensure that the SIP configs
> (which are encrypted with the Mac addr's pubkey, and thus only
> decryptable to that box's private key) are not clear and are not
> trivial to decrypt.

I think this is the part I'm missing. How do we go from "each box
has a pub/priv keypair" to "the SIP config is encrypted with a
specific pubkey".

/brain fart

Ahhhhhhhh.... Sasktel is already associating the MAC of the device to
a specific account.

Scott Walde wrote (a long time ago):
> C01L029.00.02_NORTEL-GENERAL.CFG (contains instructions for the
> ATA to _not_ send 411, 911, and 0 to PSTN.)
> C01L029.00.02_NORTEL-sktnsk_webcall_ca.CFG (file not found)
> C01L029.00.02_NORTEL-00028Axxxxxx.CFG (where 00028Axxxxxx is the
> MAC address of the Nortel ATA.)

That makes a lot more sense, but definitely makes in-field
diagnostics a pain in the arse.

Most of my perspective was coming from installing Max, which works a
fair bit differently. Each box comes without any associated
identifying information (as far as I recall, they don't record the
MAC address even). Then, on first boot, you give it your
registration code (based on your phone number).

> Again, not something your average butt-crack carrying installer
> needs to know or be aware of, since installation is still keyed to
> the Mac.

I'm not sure if that was supposed to be a dig at me or not :P

They do still have to ensure that the MAC is associated with the
proper SIP config though. This is the part that sucks for the
installer. None of the other hardware they are installing requires a
*specific* device to be installed at the premise.

You keep a stack of devices in your van and take one to the
customer's house and as part of the installation, you enter the
customer specific ID into the device. If the box doesn't work, it's
fine, you just run back to your van and grab another one, and put the
ID into that one instead. Having to change the MAC associated with a
particular customer will either require plugging the laptop in and
futzing around with Lotus Notes or calling in the new MAC, both of
which are a hassle :).
Received on Thu Dec 14 09:12:50 2006