Question for US Rules committee on AH capability within LX NAV computers?

On Apr 16, 3:21*pm, Don Johnstone wrote:
That is not going to work. The same private code is used in many flight
recorders, so all you have to do is break into one and break into the
software. You then have the private key for all similar flight recorders.
Mine as you put it is still intact. It is pointless relying on a private
key of any length if you are going to put it out into the world in an
easily available box, that is not security, that is total ignorance and I
suspect the penny has already dropped with the IGC as well, took em long
enough.

Don, use of a single private key for multiple units of a given
approved flight recorder model is not permissible. Each flight
recorder unit must have a unique private key. This requirement was
added to the specification in 2001 (AL4), after it was shown that one
design (since updated) had this flaw. See section 6.1 and Appendix G
of the IGC Technical Specification for GNSS Flight Recorders, if it
amuses you.

Any device that is freely available to a community at large (as
opposed to locked away in safes) can't be 100% free of security
issues, but shared private keys is not one of them...

Marc

Marc wrote:
Don, use of a single private key for multiple units of a given
approved flight recorder model is not permissible. Each flight
recorder unit must have a unique private key.

Food for thought (opening Pandora's box a little):

The VALI-xxx.EXE (or the according DLL) needs to contain all public
keys of all flight recorders of its kind.

Does everybody have to update their VALI-xxx.EXE when I send my flight
recordor for seal repair to the manufacturer?
If not, how else are new public keys distributed?

(Yes, there are other technical solutions like including the signed
certificate and the public key in the G record, but this technology
has not been documented and peer reviewed, and crypto technology that
hasn't been peer reviewed is insecure more often than not.)

Max

On Apr 17, 1:52*am, Max Kellermann wrote:
Food for thought (opening Pandora's box a little):

The VALI-xxx.EXE (or the according DLL) needs to contain all public
keys of all flight recorders of its kind.

Does everybody have to update their VALI-xxx.EXE when I send my flight
recordor for seal repair to the manufacturer?
If not, how else are new public keys distributed?

(Yes, there are other technical solutions like including the signed
certificate and the public key in the G record, but this technology
has not been documented and peer reviewed, and crypto technology that
hasn't been peer reviewed is insecure more often than not.)


There are a variety of ways this is handled with varying levels of
complexity. In general, though, the VALI program and/or DLL contains
the public side of a pre-generated pool of key pairs intended to be
sufficient to cover the entire lifecycle of the flight recorder
design. The manufacturer provides designated repair agents with key
reset hardware and/or software, which involves communication of
various one-time-only factors in both directions to set a valid
private key within the unit. In the rare event that the key pool is
exhausted, the VALI code can inform the user that a newer revision of
the software is needed. Including a manufacturer signed copy of the
public key in the G record has been proposed in the past, but there
are a number of flaws with that approach which make it unacceptable...

Marc