Re: problems with downloading flights from 302

[Nick Hill[_2_]]

At 16:49 03 September 2010, Darryl Ramm wrote:

>
>I really just don't get the process at all. The long term logic ought
>to be develop a validation program entirely independent of the
>hardware manufacturer. Given any valid IGC file and the public key
>this should be doable. There should be no ongoing need for any
>software from these small flight recorder companies. The source code
>for that validation program ought to be open source, but yes binaries
>need to be signed and blessed by the IGC.
>
>Darryl
>

Given a trace and the public key that would be possible. There are however
lots of keys to keep track of. From the spec (see section 2.8.3.1.1 on page
21) each logger has a unique private key so there is a separate public key
for every logger out in the wild, not one per manufacturer. If a security
reset is required for any reason a new private key may be installed and
hence a new public key is required.

The manufacture then produces the validation program/DLL containing all
the public keys for a long production run. If they use them all up they
have to produce a revised validation test which includes a new batch of
keys.

The IGC have decided that "As used in IGC approved recorders, the public
key is not intended to be available "in clear" to everyone, but should
be regarded as a confidential part of the IGC security system in the same
way as the private key."

Without that statement changing the existing system remains. The onus is
also then on the manufacturer to keep track and provide the validation
using all available public keys they have produced.

Nick

[Darryl Ramm]

On Sep 3, 10:27*am, Nick Hill > wrote:
> At 16:49 03 September 2010, Darryl Ramm wrote:
>
>
>
> >I really just don't get the process at all. The long term logic ought
> >to be develop a validation program entirely independent of the
> >hardware manufacturer. Given any valid IGC file and the public key
> >this should be doable. There should be no ongoing need for any
> >software from these small flight recorder companies. The source code
> >for that validation program ought to be open source, but yes binaries
> >need to be signed and blessed by the IGC.
>
> >Darryl
>
> Given a trace and the public key that would be possible. There are however
> lots of keys to keep track of. From the spec (see section 2.8.3.1.1 on page
> 21) each logger has a unique private key so there is a separate public key
> for every logger out in the wild, not one per manufacturer. If a security
> reset is required for any reason a new private key may be installed and
> hence a new public key is required.
>
> The manufacture then produces the validation program/DLL containing all
> the public keys for a long production run. *If they use them all up they
> have to produce a revised validation test which includes a new batch of
> keys.
>
> The IGC have decided that "As used in IGC approved recorders, the public
> key is not intended to be available "in clear" to everyone, but should
> be regarded as a confidential part of the IGC security system in the same
> way as the private key."
>
> Without that statement changing the existing system remains. The onus is
> also then on the manufacturer to keep track and provide the validation
> using all available public keys they have produced.
>
> Nick

Yes I know how it works, I just don't think it is necessarily the best
way. So now you have to attack the DLL to get the keys out first. I'm
not sure designing a system where the IGC controlled the encryption
algorithm more or where the public keys were in just in fact not plain-
text visible would really not have been any better.

But I should have put that more in the category of technical interest/
idle speculation. The IGC has a process that works, they have the
legacy issue that Tim mentioned and I really don't see that regardless
of what flight recorder you currently have that a technical solution
is really too hard for pilots to adopt (e.g. using DosBox if they want
to run the cheap version of Windows 64bit). It would be great if
Cambridge could get with the times and update their software, but that
is unlikely to happen.


Darryl

[mattm[_2_]]

On Sep 3, 2:12*pm, Darryl Ramm > wrote:
> On Sep 3, 10:27*am, Nick Hill > wrote:
>
>
>
> > At 16:49 03 September 2010, Darryl Ramm wrote:
>
> > >I really just don't get the process at all. The long term logic ought
> > >to be develop a validation program entirely independent of the
> > >hardware manufacturer. Given any valid IGC file and the public key
> > >this should be doable. There should be no ongoing need for any
> > >software from these small flight recorder companies. The source code
> > >for that validation program ought to be open source, but yes binaries
> > >need to be signed and blessed by the IGC.
>
> > >Darryl
>
> > Given a trace and the public key that would be possible. There are however
> > lots of keys to keep track of. From the spec (see section 2.8.3.1.1 on page
> > 21) each logger has a unique private key so there is a separate public key
> > for every logger out in the wild, not one per manufacturer. If a security
> > reset is required for any reason a new private key may be installed and
> > hence a new public key is required.
>
> > The manufacture then produces the validation program/DLL containing all
> > the public keys for a long production run. *If they use them all up they
> > have to produce a revised validation test which includes a new batch of
> > keys.
>
> > The IGC have decided that "As used in IGC approved recorders, the public
> > key is not intended to be available "in clear" to everyone, but should
> > be regarded as a confidential part of the IGC security system in the same
> > way as the private key."
>
> > Without that statement changing the existing system remains. The onus is
> > also then on the manufacturer to keep track and provide the validation
> > using all available public keys they have produced.
>
> > Nick
>
> Yes I know how it works, I just don't think it is necessarily the best
> way. So now you have to attack the DLL to get the keys out first. I'm
> not sure designing a system where the IGC controlled the encryption
> algorithm more or where the public keys were in just in fact not plain-
> text visible would really not have been any better.
>
> But I should have put that more in the category of technical interest/
> idle speculation. The IGC has a process that works, they have the
> legacy issue that Tim mentioned and I really don't see that regardless
> of what flight recorder you currently have that a technical solution
> is really too hard for pilots to adopt (e.g. using DosBox if they want
> to run the cheap version of Windows 64bit). It would be great if
> Cambridge could get with the times and update their software, but that
> is unlikely to happen.
>
> Darryl

Ultimately a signed certificate should be in the igc file, with a
signing
chain going back to one of the standard certificate roots via the
flight
recorder manufacturer's certificate. That way the verifiably correct
public key would be in the igc file, and every flight recorder could
have
its own private/public key pair. Unfortunately I believe the whole
igc
file scheme was developed somewhat previously to widespread
use of certificates, so we have this hokey process instead for
file validation.

-- Matt