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-78B, which outlines the criteria to be used to ensure that such a signature is acceptable to the FAA. Note that AC-120-78B explicitly declares that it is not binding; it describes *an* acceptible means of compliance (and not the only one).
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 ("Certified Flight Instructor") The person signing a flight entry or issuing an endorsement, aka the signer. Note that there are additional signers that are possible besides CFIs. For example, holders of ATP certificates and ground instructors can also sign logbooks or issue endorsements under certain circumstances. For simplicity, this document uses the term "CFI" but it should be interpreted to encompass any of these signing scenarios.
Student The pilot wishing to have an entry signed. As with the signer above, "student" here is meant to encompass any pilot who is receiving an endorsement or a signed flight; e.g., it can include second-in-command pilots under part 135 having their flight entry signed by the PIC.
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, readiness for a test 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. Encryption can help detect and prevent tampering.
Public/Private Key Encryption An encryption system that uses key pairs. Data that is encrypted with one key can only be decrypted with the other (and vice-versa). One key of the pair is secretly held by a single entity and is referred to as the "private key.", while its mate is widely and publicly known and is referred to as a "public key."
If the owner of the private key encrypts data that can be successfully decrypted with the corresponding public key, than one can consider the data to truly have been encrypted by the holder of the private key, thus providing a means of proving their identity.
The FAA refers to systems that use public/private key encryptions as "PKI" for "public key infrastructure."
It is important to note that PKI really only has value over a simple single-key encryption scheme (which uses the same secret key to encrypt and decrypt) when communicating between two parties.
Electronic Signature Proof that the specified signer (CFI, ground instructor, etc.) has signed the specified object, and that the object has not been modified since that time. This has the same meaning as in AC-120-78B 1.8.9, and, more specifically, 1.8.5 ("Digital Electronic Signature").
Digitized Signature An image of a handwritten signature. Not to be confused with an Electronic Signature; this maps to AC-120-78B‘s 1.8.14.
Expiration Date a CFI certificate expiration, if it has one, otherwise the "recent experience expiration" date. See AC 61-65J
A signed flight is an attestation by a CFI (or other signer) that they gave instruction to another individual on a given day (or, in the case of AC-135-43, that the recipient served as an SIC).
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.
Note that in any of the scenarios above, the flight is committed to the database before it can be signed. The act of signing is always a distinct and separate step from the act of saving to the database, in order to ensure that the flight is not modified between being signed and being committed to the database, and to ensure that the flight that is signed is what the signer reviewed.
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 is typically fairly small, so the hash can actually be a clear-text concatenation of the appropriate values. This is encrypted when stored to the database, and decrypted when read from the database, so it is not ever stored in clear-text. The fact, though, that the hash is in a regular clear-text format means that changes can not merely be detected, but that those changes can also be summarized for the user. And if the user performs a new edit that undoes the original edit, the "tampering" is undone and an invalid signature can become valid once more.
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 or recent-experience 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.
Advisory Circulars are explicitly not mandatory and not regulatory, but provide standards and guidance that generally provide a path (but not the only one) to compliance. (Personally, I love this - state the problem and solve it, rather than demanding specific implementations!)
AC-120-78B, section 2.1.2 has the following attributes for electronic signatures. They are paraphrased here, with how MyFlightbook meets that attribute.
| Attribute | Paraphrase of Requirement | How this design meets this |
|---|---|---|
| 2.1.2.1 Uniqueness | Only the person to whom the signature is attributed can be the source. I.e., can‘t spoof/impersonate | The only way to create a signature is to sign in to the CFI‘s account. Since that‘s 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 that‘s really no different than simply signing your own logbook and using a made-up (or stolen) CFI # and certificate. |
| 2.1.2.2 Identifiable | There must be a way to identify and authenticate the signer | An electronic signature requires the signer to authenticate with a username/password, which provides precisely this requirement. A digitized handwritten signature is something only the signer can produce, and it requires the addition of their credentials (certificate, relevant expiration dates) and an email address |
| 2.1.2.3 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. |
| 2.1.2.4 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." (See AC-120-78B section 2.2.2) There is no ambiguity here that can lead to someone unintentially following through with a signature. Additionally, they MUST either authenticate themselves using a password OR provide a scribble. |
| 2.1.2.5 Deliberate | It must be a proactive step to sign it; it cannot be implied, or a side-effect of another action. | As above, 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, nor is there any ambiguity about what they are doing |
| 2.1.2.6, 2.2.5 Non-Repudiation | If your signature is shown, you can‘t say "it wasn‘t 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) |
| 2.1.2.7 Permanence | The electronic signature is permanent and the information to which it is attached is unalterable without a new signature. | There is no ability provided to update a signature, and the signature itself is encrypted. As described above, if the flight hash and the current flight state do not match, then the flight has been altered and the signature is invalidated, requiring a new signature. For endorsements, there is no editing ability for anything - endorsements are never edited. |
| 2.1.2.8, 2.2.7, 2.2.8 Unalterability and correctibility | "A document, once signed, cannot be edited", and inclusion of a means to correct records |
(Yes, these seem to be contradictory requirements)
For endorsements, this is true; endorsements are inherently not editable on MyFlightbook. The only way to correct an errant endorsement is for the student to delete the endorsement and the CFI to issue a new one
However, MyFlightbook deliberately and intentionally does NOT adhere to this for signed flights; it is an overly restrictive requirement.
The owner of a signed flight may modify that flight, subject to the following:
If a signed flight is modified, the user can see precisely the changes that were made; if they choose to edit the flight back to its signed state, the signature will again be valid
Flights that have an invalidated signature may be signed again.
|
| 2.2.3 Notification | The system should notify the signatory that the signature has been affixed. | The success or failure of the signature is reported immediately. |
| 2.2.4 Signature association | It must be clear what the scope/significance of the signature is. |
For an endorsement, the entire endorsement is always visible.
For a signed flight, the scope is of that flight and the signer always is able to preview the data of the flight as part of the signing process.
|
| 2.2.6 Security | Any cryptographic keys must be protected, access is controlled, it should not be possible to sign after authority lapses (e.g., student/CFI relationship is broken, CFI closes account, or CFI certificate/experience lapses) |
2.2.6.1 - Control of keys. MyFlightbook is does encryption using a tightly controlled key set, with no external access. The keys for the encrypted signature are not exposed anywhere, and in fact, neither are the signature or the flight hash themselves.
2.2.6.2 - Ensure only intended signer can sign. The signer must authenticate themselves to digitally sign a flight or issue an endorsement; otherwise, they can affix a digitized signature
2.2.6.3 - Prevent modifications. There is no mechanism provided to edit an endorsement or to update the signature on a flight (modifications to the flight itself are described above).
2.2.6.4 - Restrict ability to sign after lapse. If the CFI closes their account or severs their relationship with the student, they can no longer issue endorsements or sign flights, but existing
signatures/endorsements will remain
|
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 who they say they are, which requires distinct authentications from a trusted 3rd party, such as validating certificates against FAA and other
subnational/national/international databases, and that is beyond the scope of what is practical.
|
| If someone has access to another person‘s account (e.g., walk up to their laptop which is signed in), they can use it | Again, this isn‘t 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 your 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-78B defines Digital Signatures as employing cryptographically generated data, and it references PKI (Public Key Infrastructure) as a technology
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 signature or the thing being signed has not been modified.
As noted earlier, PKI inherently requires at 2 or more parties to hold keys; it has no value over other cryptographic methods if the holder of the private key also has exclusive access to the public key.
The primary application of PKI in MyFlightbook would be to prove that the signer is who they say they are. This would require not only that they have the private key of a private/public key pair, but wouild additionally require that an out-of-band certifying authority validate the identity (e.g., a passport agency, the FAA, EASA, etc.) and then issue secure credentials that they vouch for.
All of this is out of scope for the MyFlightbook system - PKI for this purpose may be cryptographically secure, but it is well beyond what is practical to achieve, and thus simpler cryptography is employed instead.
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-78B 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 required 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.
Alas, old habits die hard. While the authenticated methods are vastly superior and do not require a handwritten signature, MyFlightbook does provide the signer the ability if they choose to create a default scribble (much like a rubber stamp with ink pad) that will show next
to authenticated signatures. It is important to stress that this is eye candy with no functional value, but it does satisfy some sort of primal need to see a handwritten scribble. When a signature is displayed for such decorative purposes, it includes
an icon of a rubber stamp 
to indicate that no unique scribble was provided for that specific electronic signature.
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 instructor cannot sign. By design. UPDATE Dec 2024: The FAA has removed the expiration for an instructor certificate; instead, there is now a "Recent Experience" expiration. A CFI must have done one of a number of activities (see AC 61-65J) to maintain their certificate.
Also note that there are other scenarios where no expiration is required (ground instructors, ATPs, etc.); MyFlightbook relaxes the requirement in these scenarios
There are a few adminstrative actions outside of the control of the pilot or the signer of a flight that can invalidate the signature on a properly signed flight. The primary one is where database maintenance may migrate an aircraft from one ID to another. An example of where this occurs is when two identical aircraft in the database are merged into a single aircraft. This invalidates the hash for the flight, even though the details of the aircraft have not changed. One advantage of having a reversable hash is that it means that the system can (and does!) implement a system to detect such issues and re-validate the signature when this (rarely) arises.
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 by the issuer (though the student can, at their own peril, delete them), nor can they be edited. And since they are not validating an underlying object, the endorsement cannot become invalid (the way that a signature on a flight can become invalid), so there there is no need to even encrypt them or compute a hash. They are simply permanent records.
The fact of the issuance of the endorsement (in an authenticated scenario) or the presence of the scribble (in the ad-hoc scenario) proves that the specified signer issued the endorsement, in its current form, subject to the same limitations described above for signed flights.
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 having authority to endorse B and has done so."
