Institutional Trust · Legal & Technical Basis
Why PresenceProof tokens
hold up.
This document is written for law enforcement officers, legal counsel, prosecutors, wildlife agency administrators, and regulatory bodies evaluating whether PresenceProof-generated records constitute reliable digital evidence under applicable standards.
Section 01
The Claim
This claim rests on five independently verifiable technical properties, each grounded in published standards and applicable to the requirements established in Lorraine v. Markel American Insurance Co., 241 F.R.D. 534 (D. Md. 2007) — the leading federal case on ESI admissibility — and its progeny.
The five properties are: hardware-attested device identity, cryptographic payload integrity, third-party timestamp non-repudiation, dual independent GPS correlation, and solar context calculation from verified astronomical data. Each is analyzed in the sections below.
Important scope limitation: PresenceProof tokens constitute corroborating evidence of presence and time. They do not establish intent, identity in the legal sense (they establish device possession, not legal personhood), or facts beyond what the token contains. Their evidentiary weight is strongest as corroboration of other evidence and weakest as standalone proof of identity.
Section 02
Cryptographic Architecture
A PresenceProof token is a structured JSON payload signed by two independent cryptographic signing chains and optionally co-signed by a trusted timestamp authority. The architecture is described below, with the primary standard governing each layer cited.
Apple Secure Enclave — Tamper-Resistant Hardware (×2)
Both the Apple Watch and paired iPhone contain a dedicated hardware coprocessor — the Secure Enclave Processor (SEP) — physically separate from the application processor. Cryptographic keys are generated inside the SEP and cannot be exported, accessed by any software (including iOS or watchOS), or extracted by physical means under normal threat models. Keys used to sign PresenceProof tokens are created inside the SEP on first application launch and never leave the hardware.
FIPS 140-3 · Apple Secure Enclave Processor · NIST CMVP Cert. · Common Criteria EAL
Apple App Attest — Hardware-Bound Application Identity (×2)
Apple's App Attest API binds each signing key to a specific application binary running on a specific physical device. Apple's own Certificate Authority issues an attestation certificate confirming that the key was generated inside genuine Apple hardware running an unmodified, App Store-distributed version of PresenceProof. Both the Watch and iPhone attest independently. Jailbroken devices and development simulators cannot generate valid attestations — the API explicitly rejects them. Per-tap assertion tokens prove each individual signing event was produced by the same attested device and application.
Apple App Attest API · DCAppAttestService · developer.apple.com/documentation/devicecheck
Dual ECDSA P-256 Signatures — Tamper-Evident Payload
The complete token payload — including GPS coordinates, timestamp, solar context, user label, and all metadata — is signed twice: once by the Watch's SEP key and once by the iPhone's SEP key. Both public keys are embedded in the token, enabling any third party to verify both signatures independently using the Web Crypto API built into all modern browsers. Alteration of any field after signing — including a single character — invalidates both signatures. Replay attacks are prevented by a cryptographic nonce (random UUID) unique to each token. The ECDSA P-256 algorithm used is a NIST-standardized digital signature scheme validated under FIPS 186-4.
ECDSA P-256 · FIPS 186-4 (Digital Signature Standard) · NIST SP 800-186 · RFC 6979
Dual Independent GPS — Correlated Location Readings
The Watch and iPhone each record GPS coordinates from their independent receivers at the moment of signing. Both readings are incorporated into the signed payload. The computed delta between the two readings is also signed. A physically plausible delta (under approximately 50 meters for two devices worn and carried by the same person) constitutes an affirmative trust signal. A large or implausible delta would be visible on verification and indicate a potential anomaly. This dual-GPS design significantly raises the cost of GPS spoofing attacks, which would need to simultaneously and consistently deceive two independent receivers.
CoreLocation (iOS/watchOS) · GPS accuracy per ICD-GPS-200 · CLLocation.horizontalAccuracy
RFC 3161 Timestamp — Third-Party Time Certification (Pro tier)
At the moment of token generation, a SHA-256 hash of the signed payload is submitted to a trusted timestamp authority (DigiCert or Sectigo) operating under the RFC 3161 Internet X.509 PKI Time-Stamp Protocol. The authority responds with a signed timestamp token embedding the hash and the certified time, signed with its own certificate chain rooted in a publicly trusted CA. This receipt is stored in the user's private iCloud container and can be unsealed when legal-grade proof is required. The RFC 3161 standard is the same timestamp mechanism underlying Adobe Acrobat's certified signatures, DocuSign, and EU eIDAS qualified electronic timestamps. Critically, the timestamp authority receives only the 32-byte hash — never the payload contents, GPS coordinates, or any personal data.
RFC 3161 (IETF, 2001) · RFC 5816 (update) · CMS RFC 5652 · eIDAS Regulation (EU) 910/2014 Art. 41
Section 03
Federal Rule of Evidence 901 Analysis
Under Federal Rule of Evidence 901(a), the authentication requirement is satisfied by "evidence sufficient to support a finding that the matter in question is what its proponent claims." As established in Lorraine v. Markel, ESI must satisfy this standard before it is admissible. The following table maps each relevant authentication method under Rule 901(b) to the specific property of a PresenceProof token that satisfies it.
| Rule | Authentication Method | How PresenceProof Satisfies It |
|---|---|---|
| 901(b)(1) | Testimony of a witness with knowledge | The token recorder can testify: "I tapped the ProveMeHere app on my Apple Watch at this time and place." The token corroborates this testimony with hardware-attested evidence that cannot be produced by any other means. |
| 901(b)(4) | Distinctive characteristics taken in conjunction with circumstances | Each token contains a unique nonce (UUID), device-specific public key fingerprints, dual GPS readings with a physically correlated delta, and solar context computed from published NOAA astronomical data for the specific coordinates and time. This combination is distinctive to the specific event and cannot be replicated. |
| 901(b)(9) | Evidence about a process or system used to produce a result, showing that the process or system produces an accurate result | This is the strongest applicable rule. The process is: (1) Apple Watch wrist authentication; (2) GPS acquisition from two independent receivers; (3) NOAA solar calculation; (4) Secure Enclave ECDSA P-256 signing (FIPS 140-3 validated); (5) App Attest assertion (Apple CA certified); (6) RFC 3161 timestamp (third-party CA). Each component is independently documented, standards-compliant, and verifiable. The process produces a token whose integrity can be independently verified by any party with access to the public keys embedded in the token itself. |
| 901(b)(3) | Comparison by expert witnesses with specimens known to be authentic | A qualified digital forensics expert can verify the ECDSA signatures, confirm the App Attest certificate chain, and validate the RFC 3161 receipt against the DigiCert CA chain — all using publicly available cryptographic tools. No proprietary analysis software is required. |
As the Lorraine court noted, Rule 901(b) provides illustrative methods only, not an exhaustive list. The court explicitly recognized that hash values and metadata constitute valid authentication mechanisms for ESI under Rule 901(b)(4). PresenceProof tokens employ SHA-256 hashing (the standard used in the court's own analysis) as a component of the RFC 3161 timestamp mechanism, providing precisely the kind of integrity verification the court identified as adequate.
The court further stated that a party "need only make a prima facie showing that [the exhibit] is what he or she claims it to be." Id. at 542. The five-layer cryptographic chain described above substantially exceeds this prima facie threshold.
Section 04
Comparison to Accepted Evidence Types
Courts already accept several forms of digital location and time evidence. The following table compares PresenceProof tokens to the most commonly accepted types on the dimensions that courts evaluate for authentication.
| Authentication Dimension | Cell Tower (CSLI) | Photo EXIF | Electronic Logging Device (ELD) | PresenceProof Token |
|---|---|---|---|---|
| Location precision | Low–Medium Tower radius 300m–30km |
Medium GPS only if enabled |
High GPS ±5–10m |
High Dual GPS ±5–10m, delta-verified |
| Timestamp tamper-resistance | High Carrier infrastructure |
None EXIF freely editable — ExifTool, Lightroom |
High 49 CFR Part 395 certified |
Very High RFC 3161 third-party CA (Pro tier) |
| Device identity verification | Medium IMEI, SIM — transferable |
Weak Camera make/model only |
High VIN-linked, certified device |
Very High Apple App Attest CA — hardware-specific |
| User presence verification | None Device only, not person |
None | None Vehicle, not driver |
Strong Apple Watch wrist detection + passcode — watch locks on removal |
| Independent third-party certification | Yes Carrier records |
No | Yes FMCSA-certified device |
Yes Apple CA (App Attest) + DigiCert (RFC 3161) |
| User-controlled generation | No Requires carrier subpoena |
Yes | No Requires regulatory access |
Yes User generates and presents voluntarily |
| Tamper detection capability | No No integrity mechanism in records |
No EXIF alterable with no detectable trace |
Partial Certified device logs |
Complete ECDSA signatures fail on any alteration |
| Requires warrant to obtain | Yes Carpenter v. US (2018) |
No | No Regulatory access |
No Voluntarily presented by holder |
The EXIF metadata comparison deserves particular emphasis. EXIF GPS and timestamp fields can be rewritten without leaving any detectable trace using freely available tools such as ExifTool. A 2025 ISACA security report classified EXIF manipulation as an underestimated cybersecurity risk precisely because courts may incorrectly assume EXIF data is reliable. PresenceProof tokens address this gap: the ECDSA signatures cover the entire payload, so any post-generation modification — including GPS coordinate substitution — produces a verifiable signature failure on the verification page.
The cell-site location information (CSLI) comparison also deserves note. Following Carpenter v. United States, 585 U.S. 296 (2018), law enforcement generally requires a warrant to obtain CSLI. PresenceProof tokens are voluntarily presented by the token holder — there is no Fourth Amendment barrier to their use as presented evidence, and no subpoena or warrant is required to read the verification page.
Section 05
Relevant Case Law
The following cases establish the legal framework within which PresenceProof tokens should be evaluated. Citations are to primary sources.
241 F.R.D. 534 (D. Md. 2007)
Lorraine v. Markel American Insurance Co.
The foundational federal case on ESI admissibility. Magistrate Judge Paul W. Grimm's 101-page opinion provides the most comprehensive analysis of how Federal Rules of Evidence apply to electronically stored information. The court held that ESI proponents must demonstrate authenticity, hearsay exception applicability, and other evidentiary requirements. The opinion explicitly identifies hash values and metadata as valid authentication mechanisms under Rule 901(b)(4), and notes that Rule 901(b)(9) — "evidence about a process or system" — is particularly well-suited to authenticating machine-generated records.
Relevance: Establishes the authentication framework. PresenceProof tokens are designed specifically to satisfy Rules 901(b)(4) and 901(b)(9) as analyzed in this opinion.
585 U.S. 296 (2018)
Carpenter v. United States
The Supreme Court held that accessing historical cell-site location information (CSLI) from carriers generally requires a warrant, finding that individuals have a reasonable expectation of privacy in the whole of their physical movements. The Court declined to extend the third-party doctrine to comprehensive digital location records.
Relevance: Establishes that government-compelled location data requires warrant protection. PresenceProof tokens are distinguished: they are voluntarily generated and presented by the token holder, not compelled from a third party. No Fourth Amendment issue arises when a hunter voluntarily shows a warden their own token.
565 U.S. 400 (2012)
United States v. Jones
The Supreme Court held that attaching a GPS tracker to a vehicle without a warrant constitutes a Fourth Amendment search. The decision addressed the physical trespass theory of Fourth Amendment protection as applied to government surveillance via GPS.
Relevance: Addresses government-placed tracking, not voluntary self-generated records. PresenceProof tokens are not tracking devices — they record a single moment at the user's initiation. Jones does not restrict their use as voluntary evidence.
152 F.3d 1241, 1249 (10th Cir. 1998)
United States v. Simpson
Cited in Lorraine as establishing that the authentication requirement under FRE 901(a) is satisfied by "evidence sufficient to support a finding that the matter in question is what its proponent claims." Courts need not achieve certainty — a prima facie showing suffices.
Relevance: Sets the evidentiary threshold. The five-layer cryptographic chain in PresenceProof substantially exceeds the prima facie standard this case establishes.
42 Akron L. Rev. 357 (2009)
Hon. Paul W. Grimm, et al., "Back to the Future: Lorraine v. Markel and New Findings on the Admissibility of Electronically Stored Information"
Judge Grimm's own follow-up law review article elaborating on Lorraine's framework. Provides additional guidance on authenticating machine-generated digital records and the role of process-and-system evidence under Rule 901(b)(9).
Relevance: Clarifies that machine-generated records with documented, reliable processes satisfy authentication requirements without requiring human testimony about each individual record's creation.
Section 06
Technical Standards Reference
Each cryptographic and technical component of PresenceProof tokens is governed by a published, publicly available standard. The following references allow independent verification of the technical claims made in this document.
RFC 3161 · IETF (2001), updated RFC 5816 (2010)
Internet X.509 PKI Time-Stamp Protocol
The governing standard for the RFC 3161 timestamp authority used in the Pro tier. Defines the request-response protocol, token format, and CA requirements. Publicly available at tools.ietf.org/html/rfc3161.
FIPS 186-4 · NIST (2013)
Digital Signature Standard (DSS)
The NIST standard governing ECDSA P-256 — the signature algorithm used to sign PresenceProof payloads. Governs key generation, signing, and verification. Publicly available at csrc.nist.gov.
FIPS 140-3 · NIST / CMVP
Security Requirements for Cryptographic Modules
Apple's Secure Enclave Processor cryptographic modules are validated under FIPS 140-3. Validation certificates are publicly listed at csrc.nist.gov/projects/cryptographic-module-validation-program. Apple support.apple.com/guide/certifications confirms current validation status.
NIST SP 800-186 (2023)
Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters
Specifies the P-256 curve parameters used in ECDSA signatures throughout PresenceProof. The P-256 curve is approved for use by US federal agencies under this publication.
Apple Platform Security · apple.com/privacy/docs
Apple Secure Enclave Architecture
Apple's published technical documentation on the Secure Enclave hardware design, key management, and security properties. Updated annually. The App Attest API is documented at developer.apple.com/documentation/devicecheck/establishing_your_app_s_integrity.
eIDAS Regulation (EU) 910/2014, Art. 41
EU Qualified Electronic Timestamp
Article 41(1) establishes that qualified electronic timestamps shall not be denied legal effect solely because they are in electronic form. This provides the strongest legislative basis for RFC 3161 timestamp admissibility in EU jurisdictions. The Pro tier's DigiCert timestamps are issued by an eIDAS-qualified trust service provider.
ISO/IEC 27037:2012
Guidelines for Identification, Collection, Acquisition, and Preservation of Digital Evidence
The international standard for handling digital evidence in a forensically sound manner. Requires hash-verified acquisition and documented chain of custody. PresenceProof's on-device signing and RFC 3161 receipt address the integrity and chain-of-custody requirements this standard establishes.
NOAA Solar Calculator · gml.noaa.gov
NOAA Solar Position Algorithm
The solar elevation calculation used to compute civil twilight boundaries in PresenceProof tokens is derived from the NOAA Solar Calculator algorithm, consistent with the Jean Meeus algorithm documented in "Astronomical Algorithms" (2nd ed., 1998). NOAA publishes reference values for validation. PresenceProof calculations have been validated against NOAA reference values to within ±2 minutes.
Section 07
Third-Party Reviews & Endorsements
The following sections will be populated as independent reviews, legal opinions, and agency endorsements are obtained. They are listed here in their anticipated form to indicate the nature of evidence that PresenceProof intends to provide and to invite participation from qualified parties.
Pending — Legal Opinion Letter
A written opinion from a practicing attorney with digital evidence expertise, analyzing PresenceProof token admissibility under FRE 901 and applicable state evidence rules. Anticipated Q3 2026. Law firms or practitioners wishing to provide this review are invited to contact us at the address below.
Pending — Independent Security Audit
A third-party penetration test and cryptographic code review of the PresenceProof token generation architecture, conducted by a recognized security firm. Findings will be published in full, including identified issues and mitigations. Anticipated Q4 2026.
Pending — Agency Acceptance Statements
Written statements from state wildlife agencies, law enforcement bodies, or regulatory agencies that have reviewed PresenceProof tokens and determined them acceptable as corroborating evidence in their jurisdiction. Agencies wishing to conduct a briefing or review are invited to contact us.
Pending — Academic Review
A technical paper co-authored with a computer science or law faculty member, submitted for peer review, documenting the PresenceProof architecture and its evidentiary properties. Anticipated 2027.
Section 08
Contact for Institutional Inquiries
Law enforcement agencies, legal counsel, prosecutors, wildlife agencies, and regulatory bodies with questions about PresenceProof's evidentiary basis are invited to contact us directly. We will provide technical briefings, architecture documentation, and sample tokens for evaluation at no charge.
PresenceProof — Institutional Trust Inquiries
JSC Biz LLC — PresenceProof Division
Email: trust@presenceproof.jscbizllc.com
We are particularly interested in hearing from:
— State wildlife agency legal and IT staff evaluating PresenceProof for field use
— Prosecutors who have encountered PresenceProof tokens as evidence
— Digital forensics experts interested in reviewing the architecture
— Law professors or researchers studying cryptographic proof of presence
— Defense attorneys with questions about the limitations of this evidence type