OLC and Cambridge 10/20/25 support ending

On Wednesday, December 7, 2011 6:03:29 PM UTC-5, Tim Newport-Peace wrote:
There is more data in the CAI file than in the IGC file.

Is this additional data (missing from the IGC file) included in the digital signature ?

Why is this additional data not just copied into the IGC file
(into a proprietary sentence) ?

On Thursday, December 8, 2011 11:16:08 AM UTC-5, Dave wrote:
If so, these loggers NEVER met the IGC requirements, correct ?

Correct. These loggers were approved in Jan '96. The first release of
the "Technical Specification for IGC-approved GNSS Flight Recorders"
was Oct '97. The approval for these loggers was grandfathered.

The loggers were approved before there was an approval procedure ?

On Dec 8, 1:33*pm, Westbender wrote:
All igc files have to abide by the same rules for validating security.
The checksum logic to build (or validate) the "G" records have to be
consistent across all manufacturers flight recorders. Otherwise we
would have a different validation routine for every manufacturer.

There ARE different validation routines for every approved flight
recorder manufacturer. In the case of Cambridge, there are two
different validation routines for the Models 10/20/25 and 302/302A.

As Dave pointed out, there should be a way to use an existing software
routine to build the correct "G" records for these files. It shouldn't
matter whose software it is. They should all come up with the same
resulting "G" records since that's what they have to generate in order
to compare for validation purposes.

Unfortunately, that's not the way it works.

I'm sure the OLC only has one
validation routine (now that the cai kluge is going away).

Of necessity, they have a number of such validation routines, either
by running the existing DOS programs and DLLs as background processes,
or using specialized manufacturer supplied code.

The only
problem associated with this is how do you verify that the igc file
came from a cai file ...AND... was "untouched". The only way to do
that is to add the "G" record creation to a single-pass cai-to-igc
converter....OR....have a website somewhere that allows you to submit
your cai file and get back an authentic igc file while giving no
access to the igc file until it is securely signed.

That could be done, but who's going to do it? Software costs time and/
or money to write and support.

There's got to be someone out there who can step up to save these
recorders.

Or, of course, one could also come up with an alternative to the OLC
that operates with no validation on an honor system. Whatever the
option, it would still cost time and/or money to come up with a
solution for a 15 year old flight recorder design that hasn't been
manufactured or sold for the better part of a decade.

I have talked to Cambridge about other software projects (I'm a
developer). They were certainly willing to listen at that time. Never
say never...

At which time and to which Cambridge? You do realize that the
Cambridge that exists now is not the same company that designed the
Model 10/20/25 and the 302/302A? To my knowledge, none of the
original employees even work there at this point...

Marc

On Dec 8, 4:31*pm, Marc wrote:
On Dec 8, 1:33*pm, Westbender wrote:

At which time and to which Cambridge? You do realize that the
Cambridge that exists now is not the same company that designed the
Model 10/20/25 and the 302/302A? To my knowledge, none of the
original employees even work there at this point...

It was around a year and a half ago regarding the 302 download
utility. I have a solution for a blue-tooth interface and wanted to
see if they were open to enhancing the 302 utility to take better
advantage of it. I offered to do the coding for them as a donation. We
chatted about it, but other priorities got in the way and I never
followed up with them.



There ARE different validation routines for every approved flight
recorder manufacturer. In the case of Cambridge, there are two
different validation routines for the Models 10/20/25 and 302/302A.


From a pure igc file perspective (not a converted cai file), if it's
true that the different manufacturers all use different methods to
generate (and validate) the "G" records, then we have a non-standard
way of securing igc files. I find that very surprising. I suppose the
reason for that is to prevent a common single method from being
cracked, thus breaking security across the board for all
manufacturers.

Just because the 10/20/25 are 15 years old and they're out of
production doesn't mean they should be written off as viable flight
recorders. There are a lot of them out there. I think it's still worth
it to look for a solution to this problem. Certainly coming up with a
way to sign a log file should be magnitudes simpler than creating an
alternative "OLC" system. From a cost perspective, there's nothing
that rules out charging a small license fee for the new conversion
program that signs the file correctly. There's just no way this can be
all that expensive and time consuming to do. It only requires a
programmer and a little time.

Here's a thought that I'd be willing to try to implement. If someone
were to "wrap" the existing cai to igc conversion program and pass the
resulting igc file (before the user can access it) through an
additional step to create a signature, that should be enough. The
developer of this process can provide a validation DLL to the OLC just
like any other manufacturer or flight computer software company. The
OLC has granted software packages like XCSoar approval. Why not
something like this? One would only have to prove that the process is
reasonably crack-proof. It's not like we need to support world record
attempts and such. We just want to be able to keep these recorders
active on the OLC.

Food for thought.

On Dec 8, 3:19*pm, Westbender wrote:
Just because the 10/20/25 are 15 years old and they're out of
production doesn't mean they should be written off as viable flight
recorders. There are a lot of them out there. I think it's still worth
it to look for a solution to this problem. Certainly coming up with a
way to sign a log file should be magnitudes simpler than creating an
alternative "OLC" system. From a cost perspective, there's nothing
that rules out charging a small license fee for the new conversion
program that signs the file correctly. There's just no way this can be
all that expensive and time consuming to do. It only requires a
programmer and a little time.

I'm not suggesting that they should be written off, just indicating
why you shouldn't expect the current Cambridge or OLC to do anything
on their dime.

Here's a thought that I'd be willing to try to implement. If someone
were to "wrap" the existing cai to igc conversion program and pass the
resulting igc file (before the user can access it) through an
additional step to create a signature, that should be enough. The
developer of this process can provide a validation DLL to the OLC just
like any other manufacturer or flight computer software company. The
OLC has granted software packages like XCSoar approval. Why not
something like this? One would only have to prove that the process is
reasonably crack-proof. It's not like we need to support world record
attempts and such. We just want to be able to keep these recorders
active on the OLC.

Both validation and conversion are handled by ancient DOS programs.
They could be run using a DOS equivalent under some sort of emulation
or virtualization environment. Should be relatively easy to wrap, as
these things go, several people have done it already...

Marc

On Thursday, December 8, 2011 4:33:26 PM UTC-5, Westbender wrote:
All igc files have to abide by the same rules for validating security.

Right.

The checksum logic to build (or validate) the "G" records have to be
consistent across all manufacturers flight recorders. Otherwise we
would have a different validation routine for every manufacturer.

Wrong. We DO have a different validation routine per manufacturer.

As Dave pointed out, there should be a way to use an existing software
routine to build the correct "G" records for these files.

No, that is NOT what I said. Again:
IFF all the information used to compute the original signature,
and the original signature are contained in the file, then it
should be possible to VALIDATE the file. It should NOT be possible
to recreate the signature as that requires the private key hidden
in the logger.

Of course, if these loggers don't each have a unique key they
are quite insecure anyway...




It shouldn't
matter whose software it is. They should all come up with the same
resulting "G" records since that's what they have to generate in order
to compare for validation purposes.

Wrong. See above.

I'm sure the OLC only has one
validation routine (now that the cai kluge is going away). The only
problem associated with this is how do you verify that the igc file
came from a cai file ...AND... was "untouched". The only way to do
that is to add the "G" record creation to a single-pass cai-to-igc
converter....OR....have a website somewhere that allows you to submit
your cai file and get back an authentic igc file while giving no
access to the igc file until it is securely signed.

No, No, No....

There's got to be someone out there who can step up to save these
recorders.

Certainly not if they are insecure in the first place.

On Dec 8, 8:26*pm, Dave Nadler wrote:
On Thursday, December 8, 2011 4:33:26 PM UTC-5, Westbender wrote:
All igc files have to abide by the same rules for validating security.

Right.

The checksum logic to build (or validate) the "G" records have to be
consistent across all manufacturers flight recorders. Otherwise we
would have a different validation routine for every manufacturer.

Wrong. We DO have a different validation routine per manufacturer.

As Dave pointed out, there should be a way to use an existing software
routine to build the correct "G" records for these files.

No, that is NOT what I said. Again:
IFF all the information used to compute the original signature,
and the original signature are contained in the file, then it
should be possible to VALIDATE the file. It should NOT be possible
to recreate the signature as that requires the private key hidden
in the logger.

Of course, if these loggers don't each have a unique key they
are quite insecure anyway...

It shouldn't
matter whose software it is. They should all come up with the same
resulting "G" records since that's what they have to generate in order
to compare for validation purposes.

Wrong. See above.

I'm sure the OLC only has one
validation routine (now that the cai kluge is going away). The only
problem associated with this is how do you verify that the igc file
came from a cai file ...AND... was "untouched". The only way to do
that is to add the "G" record creation to a single-pass cai-to-igc
converter....OR....have a website somewhere that allows you to submit
your cai file and get back an authentic igc file while giving no
access to the igc file until it is securely signed.

No, No, No....

There's got to be someone out there who can step up to save these
recorders.

Certainly not if they are insecure in the first place.

Too late Dave. Someone else already shot everything down. Sorry you
missed out.

Ok, Thanks to the folks that gave me the motivation to dive further
into this issue. After digging deeper and reaching out again to the
OLC folks, I have gotten some direction from them on how to proceed
with trying to find a solution. I've spent a reasonable amount of time
studying and researching the IGC requirements for digitally signed
flight logs, and I have put together a secure solution in the form of
a windows app and associated validation DLL.

If anyone would like to help me with some testing, please email me
privately. Only folks with 10/20/25 loggers please.

Westbender wrote:
I have put together a secure solution in the form of a windows app
and associated validation DLL.

Is there a chance you're going to release the source code of that DLL
under a free software license?

(If you think this would harm security, then it's not secure, just
snake oil.)

Max

On Dec 11, 10:54*am, Max Kellermann wrote:
Westbender wrote:
I have put together a secure solution in the form of a windows app
and associated validation DLL.

Is there a chance you're going to release the source code of that DLL
under a free software license?

(If you think this would harm security, then it's not secure, just
snake oil.)

Max

I haven't gotten that far yet. I don't think there's any reason why
the source code can't be released, although I don't know why that
would be important. All the DLL does is run the hashing algorithm and
decrypt the signature using the public key so they can be compared.
There isn't much to it. Really, the only thing that needs to be secure
is the private key that's used to create the digital signature in the
converter program. The private key is not in any way part of the
validation DLL. By the way, in case you're wondering, this software
uses 1024 bit DSA asymmetric encryption/decryption keys. The hashing
algorithm is my own and uses SHA1.

In my opinion, the most important thing is managing the private/public
key pairs and keeping them in sync. This software has to be stable so
that there is as little chance as possible for problems. If this were
to come to fruition, the slightest problem resulting in technical
support inquiries created by people monkeying around with open source
code will possibly cause the OLC to want to drop support again.
Remember this is for legacy CAI loggers only. There will be no need
for future development since the design and versions of those loggers
are static. Once this software matures, there will be very little need
for updates.

There will have to be some controlling authority to manage and release
new key pairs if the need for them (unlikely crack) ever arose.
Although I can't imagine that anyone would want to spend the effort to
crack a digital signature of this complexity on flight logs for the
OLC. I agree with most people that we should not have to go through
this crap. However since this is what it's going to take to keep these
loggers alive on the OLC, then I'm willing to give this a try.