Basic usage: verifying files
MATCHA's most central integrity features are its copy-paste block and history recording features. Suppose you are an instructor who received a submission for an activity in which you enabled copy-paste block. How do you know that the protection was enforced? And how do you know that the history included in the file is genuine?
The short answer is that you know the block was enforced and the history is genuine if (and only if) the
file passes an integrity check (a .mcha file) or has a valid signature
(for a .docx file). To check integrity on a
.mcha file, open it in MATCHA Writer and do
History > Check integrity (there is also a shortcut to check all
downloaded files in the grading interface). To verify the signature on a
.docx, select Verify .docx from the
Instructor menu (accessible from the Startup screen).
MATCHA's security layers
MATCHA enforces copy-paste block, or more generally, blocks injection of text without typing, at two distinct layers.
The first security layer is in MATCHA Writer's client code (the code running on the user's computer). This code rejects copy-paste from the system as well as any form of automated text injection we know of. It only accepts text entered by typing characters one by one on the keyboard. (Caveat: as of MATCHA beta 0.9.x, this layer does not fully protect against injection of non-Latin scripts.)
The 2nd security layer is MATCHA's
remote typing control
technology (patent pending). In a nutshell, document edits are batched into small packages,
hashed, then sent to a certification server, which returns a certificate saying, essentially,
edit package with hash value XYZ was seen at time t. The certificate's
digital signature is stored in the project history.
Since the digital signature cannot be forged and the timestamp is under the control of the remote server, not the user's computer, MATCHA is able to guarantee that the edits were made within a short time window. This allows a client reading the file to ensure characters were inserted at a normal typing speed (hence not copy-pasted en masse). Unlike the first layer of security, this layer is secure against any successful tampering with MATCHA client code (the remote server will not communicate with a modified client).
The whole of a project's history is secured in the same way through signatures from the remote certification server.
Integrity checking
Importantly, the .mcha files are not intrinsically tamper-proof. They are
standard SQLite files that can be opened and edited by anyone. However, they are
tamper-evident, in that a simple programmatic check will reveal tampering. The
files contain two main types of information:
- Current state information, such as the main document's current state.
- Historical events, such as the precise sequence of edits that led to the document's current state.
Integrity checks verify that the project is genuinely MATCHA-made and satisfies all relevant integrity policies. A number of policies are enforced. The primary policy is that the current document state must be reconstructable from the history, and all historical steps must be properly signed.
Other policies include:
- Typing rate: Characters have not been inserted faster than humanly possible through typing.
- Check-in coverage: If check-in is used, all edits must bear certified timestamps within the covered check-in periods.
- Outage coverage: If some edits were made in outage mode, they must be covered by outage periods reported to the management service.
- Taint percentage: Tainted characters must not exceed a certain percentage of the whole document.
Explanation of taints: For efficiency reasons, edits in MATCHA are not immediately certified by the server. This means that an unexpected termination can leave some characters written in the document but without a certified timestamp. On reopening the app, MATCHA will see these uncertified characters and request certification for them. This recovery mechanism opens a small security loophole: what if a user manually added the characters to the file while MATCHA was closed? (Tampering with the file while MATCHA is open would be detected, and MATCHA would refuse to continue working with it.) To close that loophole, any uncertified characters found on project open are marked as tainted and certified as such. A few tainted characters are allowed, but integrity checking will fail if too many are detected, meaning more than could ever occur through occasional unexpected app terminations.
There is a little bit of built-in forgiveness for all policies. For typing speed and taint, a small percentage of violating characters is allowed. For document match, some very minor mismatches will be ignored. Substantial mismatches, however, will result in integrity check failures.
Normally, a student's file should pass integrity checks. If it fails, this can indicate an attempt to tamper with the project's history (that said, MATCHA remains in beta and some integrity-check failures may be due to bugs; in case of doubt, contact technical support).
Snapshotting and automatic integrity checks
Since projects can accumulate long histories and replaying an entire project can be slow, MATCHA
automatically creates certified snapshots throughout the life of a project. Snapshots contain all the
information necessary to produce history analyses, .docx exports, or
integrity reports. So that they can be trusted, they are produced and signed by a remote server based on a
project's history. The server performs an integrity check each time it creates a snapshot. This allows any
integrity issues to surface relatively early.
If a snapshot fails an integrity check, you might see an error to the effect that the project has lost integrity. MATCHA will then offer to repair the project. This will not repair excessive character taints or input speed failures, but it can repair a mismatch between the current document and the history. The repair simply replaces the current document with the result of replaying the history.
Bottom line
The .mcha file format is not intrinsically tamper-proof. What prevents
MATCHA projects and their histories from being forged are the non-forgeable certificates they contain.
These certificates prove that edits were made within MATCHA within certain narrow time windows, possibly
also within certain check-in periods. To ascertain that a .mcha file is
genuine, an integrity check must be run on it.