# MZAP--Mobile Application for Basketball Match Tracking and Digitalization of Endgame Reports
## 5 MZAP Android Application--Match Report Preview and Digital Signing
### Security Mechanisms for PDF Match Endgame Reports
#### 5.2.3 Trust Model and Verification  
As stated earlier, upon receiving the hashed passwords, the MZAP application generates the PDF file and locks and encrypts it using the provided passwords. The PDF is then signed and a PDF file size in bytes is calculated followed by computation of a 64-character BLAKE3 [35] cryptographic hash of the entire PDF content. The accompanying JSON (*.mzap) file, that is alongside PDF file sent to the MZAP server, is similarly processed to obtain its file size and BLAKE3 cryptographic hash. All of these data are transmitted back to the MZAP server and associated with the previously stored password hash.  
PDF file generation occurs only after the match report is finalized and no further modifications are expected. If a user wishes to review the report for inconsistencies, a  
Figure 22: Match report PDF document properties.  
\"Preview Report\" option is available. In cases where the user needs to amend the report, the MZAP administrator must be notified to invalidate the previously stored data, thereby allowing the user to regenerate and re-sign the PDF.  
The act of generating the PDF file signifies that the user has finalized the report and is requesting the document to be locked, encrypted, and digitally signed for archival purposes. Only PDF files that can be decrypted using the user's hashed password, unlocked using owner's hashed password, match the expected file size in bytes, and resolve to the predetermined cryptographic hash are accepted into the digital archive. These are the essential prerequisites for a file to be deemed valid, and they collectively serve to verify that the PDF has not been tampered with. Mentioned validation steps are performed on the MZAP server, a backend system developed using the.NET Core framework and the C# programming language. Since PDF files are locked, encrypted and digitally signed, a custom MZAP viewer was made to enable efficient document preview.  
Server-side PDF certification validation using PDFsharp and BounceCastle libraries involves several key steps. First, the PDF document containing a single hidden signature is opened using the appropriate password. Next, the internal structure of the PDF is carefully parsed to locate the embedded digital signature. In this case, the signature exists as an annotation object rather than a visible form field. For this signature, PDFsharp helps extract the raw cryptographic blob and the crucial byte ranges, which BounceCastle then uses to compute a hash of the document's signed content. This computed hash is then compared against the hash embedded within the signature's cryptographic data to verify document integrity.  
If the password is compromised, the PDF file could be altered. However, since the PDF consists solely of generated images, modifications require image editing software. Such edits typically result in changes to both the file size and content hash. Even if the file size remains unchanged, the content hash would differ, thereby flagging the file as altered. JSON files are validated similarly, excluding the hashed password requirement, as they are not password-protected.  
The primary function of the QR code embedded in each PDF report is to store the match UUID, facilitating easier identification and lookup. To initiate report validation, the UUID is extracted from the QR code, and the tamper detection procedure is carried out using the associated hashed password, file size, and cryptographic hash.