A method is needed by which an instructor can sign a student’s logbook, or by which an instructor can endorse a student. Reference is made to FAA circular AC No: 120-78A, which outlines the criteria to be used to ensure that such a signature is acceptable to the FAA.
This document describes the implementation used by MyFlightbook. It has NOT been vetted by the FAA (indeed, the FAA does not appear to certify compliance); it is a description of how I have chosen to implement my interpretation of the requirements.
CFI = The instructor ("Certified Flight Instructor). The CFI must have a CFI certificate with an expiration date in the future.
Student = The pilot wishing to have an entry signed. A student need not be a not-yet-licensed pilot; the student is ANY pilot who receives instruction from a CFI.
Signed Flight = A flight entry in a student's logbook which includes CFI comments and a CFI attestation that the training described has taken place during that flight. I.e., this is what the CFI fills out in a paper logbook at the end of the flight.
Endorsement = An indication by a CFI that the student has met some required level of accomplishment, fulfilled a periodic requirement, or is otherwise authorized to perform various flying activities. I.e., this is not tied to a particular flight, but rather are the items typically found at the back of a paper logbook, such as a tailwheel endorsement, student-pilot solo authorization, etc.
Ad-Hoc = A signature provided when the student and the instructor do not have accounts on MyFlightbook that are linked in a student/instructor relationship. The signing of a flight is a one-off event, and it is not necessary for the instructor to ever even have an account on MyFlightbook.
Authenticated = A signature where the student and the instructor each have an account on MyFlightbook, and where their accounts are linked in a student/instructor relationship, and where both must authenticate themselves to the system.
Mobile = A signature that is provided face-to-face on the student’s mobile device; e.g., as might happen in the hangar immediately following a flight. Note that it is on the student’s device because it is the student’s logbook that is being signed.
Remote = A signature that is provided asynchronously via the web. It does not require that the student and CFI be together, nor the presence of a mobile device. This is ALWAYS authenticated.
Hash = A deterministic unique output of an operation performed on an object which changes if the underlying object changes. In most applications of a hash, the hash is small relative to the size of the object being hashed, but is highly sensitive to changes in the underlying object. The key attribute of a hash is that you can compare the hash of an original object and the hash of the new object, and if the new object differs even slightly from the old, the hashes will be different with an exceedingly high probability (or, stated another way, the odds of the underlying objects being different but the hashes being the same is vanishingly small), and hashes are much quicker to compare than entire objects.
Encryption = The transformation of data into an encoded form that obscures the underlying data. Encrypted data requires a key to decrypt.
Electronic Signature = CFI Signature = proof that the specified CFI has signed the specified object, and that the object has not been modified since that time.
Digitized Signature = an image of a handwritten signature. Not to be confused with an Electronic Signature.
A signed flight is an attestation by a CFI that they gave instruction to another individual on a given day.
There are 4 basic scenarios to support. In descending order of importance, these are:
These scenarios are discussed in more detail below
In the current implementation, this is done via web page served (securely) from the MyFlightbook server, and requires authentication from the STUDENT’s account.
The digitized signature is stored as a PNG file with the flight record.
It is important to detect if an entry has been tampered with. For this reason, we capture a hash that identifies the flight object’s state at the point of the CFI’s signing. This should be fairly small, so the hash can actually be a clear-text concatenation (which has the advantage that it truly will deterministically catch any change), and there is really no need for encryption, as long as we can assume that the CFI record cannot be modified (which is a business rule that we enforce).
The hash of the flight object consists of a string that is a concatenation of:
For database efficiency, we truncate the hash at 255 characters, which as a practical matter cuts off comments occasionally but rarely.
Excluded from the signature are values which the student should be allowed to change without invalidating the underlying signature:
When a flight is signed, the following state information is stored with the flight record:
The CFI’s name and email can be extrapolated from the account identified by the username. However, we will keep a cache of the email and name used at the time of signing in case either changes, or in case the account is subsequently deleted, since a valid signature does not stop being valid when the CFI’s account goes away.
The Student’s name and email can be extrapolated from the linked flight.
A flight can only be signed once and by one instructor. Any new signature will overwrite the old one.
A flight signature can be in one of 3 states:
Note that in computing validity, the presence of a certificate expiration date is all that is required, the actual date of the expiration is not relevant for the validity of the signature. See the discussion below of enforcement for how we ensure that only unexpired certificates are allowed for signing.
A CFI is only allowed to sign student flights if they have provided in their profile:
Due to potential time-zone issues between the time zone of the MyFlightbook server (currently Pacific time zone) and where the CFI may be, we allow a 24-hour grace period before deeming an expiration date to have passed.
A CFI is only allowed to sign a specific flight if:
Note that the student/instructor relationship only need live for the duration of the signing process. Once an entry is signed, the relationship can be severed without affecting the validity of the existing signature.
AC120-78A has the following attributes for electronic signatures, paraphrased here:
There are a few potential holes here, the risk of each of which is acceptable:
AC120-78A defines Digital Signatures as employing cryptographically generated data and using public/private key technologies to avoid spoofing, etc.
The purpose of a cryptographic signature is really twofold: (a) it authenticates the fact that the signer actually signed it, and (b) it proves that the thing being signed has not been modified. The purpose to using cryptography and public/private keys is to ensure that the signature itself is not tampered with.
For example, in a digitally signed email message, the signature enables proof that the message has not been tampered with, and the signature can also only be produced by the sender, which validates that they produced it. (The message itself, in this scenario, is kept in the clear.)
The only way to have cryptographically secure identification of a person’s identity is to have an out-of-band certifying authority that validates the identity (e.g., a passport agency, or the FAA (or one of its international equivalent), or driver’s license, etc.) and then issues secure credentials that they vouch for. This is out of scope for the MyFlightbook system.
While we cannot validate that an account holder is who they say we are , we can verify a few things:
MyFlightbook performs two integrity checks to detect tampering with or forging of the signature:
So, if a malicious user were to gain access to the database, they could not forge a signature because they could not store a propertly compute and encrypted hash that would match subsequent comparisons. Nor could they modify an existing signature for the same reason.
With the proliferation of touch-sensitive smartphones and tablets (particularly among pilots), and the fact that the student and pilot are together at the end of a lesson, the convenience of capturing a digitized signature right then in there is certainly much greater than forcing the CFI to both create a MyFlightbook account and to set up a relationship with the student. This is why we have the “Ad-hoc” scenario described above.
AC120-78A does allow for digitized handwritten signatures, and MyFlightbook supports this functionality.
To do that, however, requires addressing the non-repudiation and traceability issues above. An image of a signature is easily reproduced, and also easily forged. Stated another way, the FAA circular requires some way to authenticate that the signer is the signer. (Ironically, this is a tougher requirement than for paper signatures.)
The authenticated methods above provide this: the signing MUST come from a SPECIFIC, SEPARATE, AUTHENTICATED account. Capturing a digitized handwritten signature provides no way to determine that it wasn’t from the student himself. However, since it is done via the student’s account and in their presence (since it is via their device and signed in to their account), it CAN prove that the student accepted the signature. For this reason, we require the student to positively affirm that it is the instructor who is signing. (Sort of the student-signing-the-instructor-signing-the-student.)
Nevertheless, a digitized signature is a less traceable mechanism and is easier to repudiate than the non-signature model, but it does provide a lightweight alternative.
The ad-hoc scenario is designed for this. It does require the use of the mobile app (for touch-screen access) and physical presence.
A simple email exchange can establish the relationship. Either party may initiate, using the website. An email is sent to the non-initiating party, which includes a link; following the link goes back to the website, where the account is authenticated (and created, if needed) and the relationship can be accepted.
This would be a very rare race condition because signing can only happen to an extant flight. E.g., you'd have to start the signing process in one place and then delete the underlying flight after the signing process has started but before it has finished. But even then, this would be caught: because the signature is a part of the flight record (as opposed to a separate record that is tied to the flight), the update of the flight would fail since the original flight would no longer be in the database.
This instructor cannot sign. By design.
An endorsement is a certification by the instructor that the student is competent and (as appropriate) authorized for certain flights. Typical examples of endorsements include solo operations, tailwheel sign-off, readiness for a check-ride, etc.
Endorsements are not tied to an individual flight (which is why they are in the back of the book for paper logbooks), and as such are much simpler than signed flights discussed above. (For this reason, MyFlightbook implemented them much earlier than signed flights).
Endorsements largely follow the same model as for signing flights (above), but with a few small differences:
Endorsements cannot be deleted or edited, and since they are not validating an underlying object such as a flight, there is no need to even encrypt them or compute a hash, and there is no notion of endorsement becoming invalid.
In 2018, a few validations were relaxed:
Each endorsement consists of the following:
All of the other discussion above concerning signatures applies here as well.
To be clear, an endorsement on MyFlightbook technically does not mean “CFI A endorsed student B”, but rather “The person who has authenticated access to account A and the person who has authenticated access to account B have identified A as being a CFI for B, and has endorsed B”