OLC and Cambridge 10/20/25 support ending

On Dec 11, 12:59*pm, Westbender wrote:
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.

I'm a bit confused as to what you are doing. Are you simply hashing
the contents of the supplied IGC file, appending a new signature, then
providing code to the OLC so they can verify the new signature? How
does the OLC verify that the newly signed IGC file is, in fact, a
valid copy of the CAI flight data file originally downloaded from the
GPS-NAV?

Marc

On 12/11/2011 4:20 PM, Tim Newport-Peace wrote:

The only way I can see for it to be in any way secure is for the
application to:

Read the .CAI file
Perform a Validation Check.
If Validation Passes:
Create an IGC file
Digitally sign it as proposed.
Else Abort.

Otherwise there is no chain of evidence.

For this to be acceptable to IGC (as against OLC), I guess that it would
need to be a Server-Side application.

Tim Newport-Peace

"Indecision is the Key to Flexibility."

This is exactly what it does. It does not need to be acceptable to igc,
the binary file is still acceptable to them. This is an OLC only fix,
since they can't, or won't, handle the binary file directly.

A server-side application using this code would be more secure, but this
is far better than the PDA files already accepted. If it goes on a
server, why not on the OLC server? They handle zipped igc files, so its
not a binary upload constraint. They handle DOS validation tools
already. Seems weird from out here.

-Dave

The only way I can see for it to be in any way secure is for the
application to:

Read the .CAI file
Perform a Validation Check.
If Validation Passes:
* * * * Create an IGC file
* * * * Digitally sign it as proposed.
Else Abort.



Bingo

This is exactly what it does. It does not need to be acceptable to igc,
the binary file is still acceptable to them. This is an OLC only fix,
since they can't, or won't, handle the binary file directly.

A server-side application using this code would be more secure, but this
is far better than the PDA files already accepted. If it goes on a
server, why not on the OLC server? They handle zipped igc files, so its
not a binary upload constraint. They handle DOS validation tools
already. Seems weird from out here.

-Dave

Dave is correct. The only relevance it has to the IGC is that we're
abiding by their specifications for securing and digitally signing the
resulting .igc file. This is an attempt to create a conversion process
that takes a proven secure .cai file and produces a secure .igc file
from it. This is not a solution for badges, records, real-life
contests, etc. This is an OLC-only proposal. Although lets not get
ahead of ourselves. It's probably unlikely that we can pull this off,
but it's worth a try. It's certainly technically feasible as I already
have a working prototype. The real challenge is getting involvement
from the right people to help us with an attempt to get an approval
from the OLC.

On Dec 11, 6:04*pm, Westbender wrote:
This is exactly what it does. It does not need to be acceptable to igc,
the binary file is still acceptable to them. This is an OLC only fix,
since they can't, or won't, handle the binary file directly.

A server-side application using this code would be more secure, but this
is far better than the PDA files already accepted. If it goes on a
server, why not on the OLC server? They handle zipped igc files, so its
not a binary upload constraint. They handle DOS validation tools
already. Seems weird from out here.

-Dave

Dave is correct. The only relevance it has to the IGC is that we're
abiding by their specifications for securing and digitally signing the
resulting .igc file. This is an attempt to create a conversion process
that takes a proven secure .cai file and produces a secure .igc file
from it. This is not a solution for badges, records, real-life
contests, etc. This is an OLC-only proposal. Although lets not get
ahead of ourselves. It's probably unlikely that we can pull this off,
but it's worth a try. It's certainly technically feasible as I already
have a working prototype. The real challenge is getting involvement
from the right people to help us with an attempt to get an approval
from the OLC.

I''ll be honest, in my opinion, unless the validation, conversion from
the CAI binary file to IGC format, and generation of digital signature
are done as consecutive steps in a secure environment (on a server
belonging to the OLC or a trusted third party), all that is being
created is a nice illusion. The OLC wants a signature to validate,
and they'll get one, even if it doesn't prove anything about the
actual source of the data in the IGC file. I have the same
reservations about accepting as "secure" digitally signed IGC files
produced by PDA/PNA software. Personally, I don't understand why the
OLC even bothers validating the files, it's extra work for them, and
it's not like anyone is winning anything except some bragging rights.
Better that all involved understand that it is possible to produce
fake IGC files, and shun those who are caught doing so.

If you distribute the program to end users, with or without the source
code, there are going to be ways to trick it into applying the
signature to an arbitrarily modified IGC file, such as providing fake
versions of VALI-CAM.exe and CONV-CAM.exe. Plus, of course, the
private key must be present in the program, which means someone with
patience can determine what it is. If the computer and software are
under end-user control, I don't see any easy way to prevent these
sorts of things...

Marc

I''ll be honest, in my opinion, unless the validation, conversion from
the CAI binary file to IGC format, and generation of digital signature
are done as consecutive steps in a secure environment (on a server
belonging to the OLC or a trusted third party), all that is being
created is a nice illusion. The OLC wants a signature to validate,
and they'll get one, even if it doesn't prove anything about the
actual source of the data in the IGC file. I have the same
reservations about accepting as "secure" digitally signed IGC files
produced by PDA/PNA software. Personally, I don't understand why the
OLC even bothers validating the files, it's extra work for them, and
it's not like anyone is winning anything except some bragging rights.
Better that all involved understand that it is possible to produce
fake IGC files, and shun those who are caught doing so.

If you distribute the program to end users, with or without the source
code, there are going to be ways to trick it into applying the
signature to an arbitrarily modified IGC file, such as providing fake
versions of VALI-CAM.exe and CONV-CAM.exe. Plus, of course, the
private key must be present in the program, which means someone with
patience can determine what it is. If the computer and software are
under end-user control, I don't see any easy way to prevent these
sorts of things...

Marc

Marc, are you willing to get involved? Lot's of people have opinions
and are willing to shoot stuff down. Very few of them step up and
offer solutions and help. Are you a software guy? How about it?

I agree that a "black-box" web-service that accepts a cai file and
returns a digitally signed igc file would be the ultimate solution. I
have been considering that as well. The interesting thing is that the
OLC is exactly that. However, they won't do the little bit of work
required to do this conversion. They act like it takes too much time
and effort. I claim otherwise. In a matter of hours, I created a small
app with the original Cambridge programs (VALI-CAM.exe and CONV-
CAM.exe) embedded, which provides a single-pass process for validating
the cai, converting it to igc and digitally signing it. I don't claim
that this solution is 100% crack-proof and maybe someone with enough
hacking talent could do it. I believe the hashing and digital
signature is very secure assuming the private key is protected. I
suppose there's always some yahoo out there that likes a challenge
though.

Folks have to play by the OLC's rules if they want to post their
10/20/25 flight logs there. This is one possible solution that didn't
take much effort. Proving that it's viable and acceptable to the OLC
is another matter. I don't know what their "security threshold" is for
approval. They do accept files from PDA software, so the bar really
isn't that high.

On Dec 11, 9:44*pm, Westbender wrote:
Marc, are you willing to get involved? Lot's of people have opinions
and are willing to shoot stuff down. Very few of them step up and
offer solutions and help. Are you a software guy? How about it?

I already am involved, how do you think I know about this stuff?

;^)

Marc

Westbender wrote:
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.

For people who don't run 32 bit Windows on an Intel CPU.

For people who don't to run "untrusted" closed-source software.

Practical example: I want to download and verify the flight from the
Cambridge with my Streak running Android. The Streak has an ARM CPU,
so even if I wanted and even if Windows would run on it, there would
be no chance to use your DLL. None of my computers runs Windows,
anyway.

The majority of devices sold currently have an Intel CPU, and the
majority of devices sold currently don't run Windows.

If you're not convinced that disclosing and freeing the source code is
important, I can elaborate more.

Max

Marc wrote:
I''ll be honest, in my opinion, unless the validation, conversion from
the CAI binary file to IGC format, and generation of digital signature
are done as consecutive steps in a secure environment (on a server
belonging to the OLC or a trusted third party), all that is being
created is a nice illusion.

You're right by saying it's an illusion, but I strongly disagree that
a server-side service is a viable solution.

What if you don't have internet access?

What if the server is down?

What if the server is commercial (like the OLC), and I object to use
that?

What if the server operator abuses his powers to censor criticism on
his site (like the OLC), and I object to use censorship-promoting
services?

What if I want to attend to a contest that is independent of IGC and
independent of OLC? In the middle of the desert, without any chance
to hook up to the 'net?

What if the server gets hacked, and the server's private key gets
disclosed? This hack will retroactively invalidate all existing
signatures. This can be recovered by re-signing all files by using
the original Cambridge files, but this is a big practical challenge,
maybe practically impossible; does the pilot really have a backup?
Will you get all pilots to resubmit all backups? (Certificate
authorities do get hacked, see DigiNotar and others)

This problem is not something that should put Cambridge owners in a
dependency situation on one entity. This problem can be solved with a
free tool that does not require internet connection, and that does not
require this kind of dependency. If such a solution is possible, it
should be done that way.

If this can technically only be achieved by storing the whole verbatim
Cambridge file (including the verbatim signature; using base64?) in
the IGC file, then be it so. It's not 1995 anymore, and inflating the
IGC files is the lesser evil.

Max

Max Kellermann wrote:
The majority of devices sold currently have an Intel CPU, and the
majority of devices sold currently don't run Windows.

I mean the majority "don't" have an Intel CPU (but an ARM). It's
too early in the morning in my time zone! ;-)

Max