A method is needed by which an instructor can sign a students 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 students mobile device; e.g., as might happen in the hangar immediately following a flight. Note that it is on the students device because it is the students 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 STUDENTs 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 objects state at the point of the CFIs 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 CFIs 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 CFIs account goes away.
The Students 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:
| Attribute | Paraphrase of Requirement | How this design meets this |
| a) Uniqueness | Only the person to whom the signature is attributed can be the source. I.e., cant spoof/impersonate | The only way to create a signature is to sign in to the CFIs account. Since thats already a strong form of authentication for everything else in the system, it should work here too. This is actually harder to spoof than a physical signature is to forge. One could theoretically create a 2nd account on MyFlightbook and use that to sign with, but thats really no different than simply signing your own logbook and using a made-up (or stolen) CFI # and certificate. |
| b) Control | The signer must be the only person who controls the signature | An electronic signature requires the signer to authenticate with a username/password. A digitized handwritten signature is something only the signer can produce. |
| c) Notification | The system should notify the signatory that the signature has been affixed. | The success or failure of the signature is reported immediately. |
| d) Intent to sign | The signatory should be prompted to ensure that they realize they are signing using one of several key phrases, such as "Signed by". | The user interface uses the phrase "Signed by" |
| e) Deliberate | It must be a proactive step to sign it; it cannot be implied, or a side-effect of another action. | The signature must be requested by the student, or optionally explicitly provided by the instructor. There is no way it is a side effect of some other action. |
| f) Signature association | It must be clear what the scope/significance of the signature is and the signature must be attached to the record. | Scope is always a single flight, nothing more. (Same applies to existing endorsements as well), and the signature is stored as an integral part of the flight record. |
| g) Retrievable and traceable | There should be a way to trace back to the individual who signed, and provide a way to identify records that they have signed. | The account name (for electronic signatures), full name, CFI Certificate/expiration, and email (as of the time of signing) are all captured, providing multiple paths to the signer. The signer can also view any electronic endorsements that they have issued. As of this writing, the CFI cannot see all flights that they have signed, though; but this is no different from a paper logbook, where it is impossible to access signed flights without getting the logbook from the student. |
| h) Undeniable | If your signature is shown, you cant say it wasnt me. | Only the authenticated user described above can sign, and the hash comparison will only work for that CFI. Specifically, we can prove that the signature came from someone with access to a specific second account. The hash is also encrypted using the username of the CFI, so any attempt to change this back-trace will invalidate the signature. In the ad-hoc scenario, the signature provides non-repudiation at least as good as a handwritten signature (similar to what grocery store credit-card check-out tablets capture) |
| i) Security | Tampering must be evident and the signature voided when tampering occurs, impersonation (again) must not be possible, it should not be possible to do after authority lapses (e.g., student/CFI relationship is broken or CFI certificate expires) | No mechanism is provided for modifying a signature; the only option is to re-sign. The stored hash of the flight in the state when it was signed ensures that the signature is treated as invalid if the underlying flight is modified. |
| j) Permanent and unalterable | The signature must be a permanent part of the record, and altering the data should require a new signature | The signature is stored with the flight record and any edit to the underlying object invalidates the signature. There are some aspects of the underlying flight which are considered "incidental" and excluded from the set of invalidating edits, such as images or flight telemetry (as described above); this is a deliberate judgment that the signature should apply to the "core" attributes of the flight. |
| k) Identification and Authentication | Need to be able to uniquely identify the signer. | The signature includes the CFI # and expiration along with other identifying details, such as email address. Uniqueness is determined either by the signer providing their username/password, or by providing their handwritten signature |
| l) Correctable | There should be a means for the pilot to edit the underlying flight and to get a new signature. | Any update to the core (signed) fields of a flight immediately invalidates the signature, and this is displayed to the user. A new signature can be subsequently requested. As a bonus, if the core data is restored to the state at which it was signed, the signature will be re-validated (since the hash will match again). |
| m) Archivable | There must be a means of archiving the signed flight | Since the signature is part of the flight object, it is automatically backed up as part of the nightly archiving process. |
| n) Control of private keys and access codes | Basic security - don't expose passwords or private keys. | The keys for the encrypted signature are not exposed anywhere, and in fact, neither are the signature or the flight hash themselves. |
There are a few potential holes here, the risk of each of which is acceptable:
| Risk | Mitigation |
| We are authenticating accounts, not people. If one account is used to sign on behalf of another, we can know that they are distinct accounts with distinct email addresses, but we cannot actually know anything about the people who created the accounts beyond that. It is possible for a student to create two accounts and use one as a CFI account. | The issue here is not a hole in the system so much as it is fraud on the part of the user. Also, the only way to truly get around this is to have some additional cryptographic means of ensuring that the two account holders are in fact distinct people (e.g., distinct authentications from a trusted 3rd party, such as validating certificates against FAA and other national/international databases), and that is beyond the scope of what is practical. |
| If someone has access to another persons account (e.g., walk up to their laptop which is signed in), they can use it | Again, this isnt so much a hole in the system as it is poor security on the part of the user: if you leave your bank web page up and logged in, a passerby could embezzle money from their account. This level of risk is acceptable |
| If the user can gain direct access to the database, one can spoof another CFI providing the signature. | We treat database security very seriously. If it is compromised, lots of mischief can occur. However, we encrypt the flight hash so that it is (essentially) impossible to avoid detection of a modification of a flight, and we create an encryption of the signature details (CFI username, expiration date, certificate, etc.) so that we can detect modification of those as well. The encryption happens outside of the database, so even if someone were to gain access to the database, they could not produce a properly encrypted signature. |
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 persons 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 drivers 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 wasnt from the student himself. However, since it is done via the students 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
