The Physiological Signal

Every time your heart beats, it pushes a wave of blood through your arteries and into the capillaries beneath your skin. That wave of blood changes how much light your skin absorbs versus reflects. The change is invisible to the naked eye, but it is measurable by a camera.

Remote photoplethysmography (rPPG) captures these sub-pixel color fluctuations from ordinary RGB video. By analyzing the green, red, and blue channels of each video frame across time, signal processing algorithms extract a waveform that corresponds to your cardiac cycle. This is the blood volume pulse (BVP), and it carries the same timing information as a clinical pulse oximeter or ECG lead.

How It Works

When light hits your face, some of it is absorbed by hemoglobin in your blood and some is reflected back. During systole (when the heart contracts), more blood fills the capillaries, increasing absorption and decreasing reflected light. During diastole (when the heart relaxes), blood volume drops and more light is reflected. This creates a periodic oscillation in the green channel that directly tracks your pulse rate.

The signal is strongest in the green wavelength (around 520-580nm) because hemoglobin has a strong absorption peak there. Red and blue channels carry complementary information that helps separate the cardiac signal from noise sources like ambient light changes, subject motion, and camera sensor noise.

Published Evidence

A 2025 PRISMA-compliant systematic review by Debnath and Kim in BioMedical Engineering OnLine analyzed 145 peer-reviewed articles spanning 2008 to 2025. The review covered signal processing foundations (ICA, PCA, CHROM, GREEN channel methods), supervised machine learning approaches, and end-to-end deep learning architectures including CNNs, 3D CNNs, LSTMs, Transformers, and GANs.

The key finding: deep learning end-to-end models substantially outperform traditional signal processing across all major benchmark datasets. The improvement is consistent across lighting conditions, motion artifacts, and skin tone variation.

These benchmark datasets (UBFC-rPPG, PURE, MAHNOB-HCI, VIPL-HR, COHFACE, MMPD) span controlled lab settings and unconstrained real-world conditions. Sub-beat-per-minute precision from a consumer camera, no physical contact required.

Why CHROM

PulseProof uses the CHROM (Chrominance-based) algorithm as its primary rPPG signal extraction method for camera-based liveness detection. Developed by de Haan and Jeanne and published in IEEE Transactions on Biomedical Engineering in 2013, CHROM was designed specifically to handle the real-world conditions that make rPPG difficult: changing ambient light, subject motion, and varying skin tones.

CHROM works by projecting the RGB color signal into a chrominance space that separates the blood volume pulse from specular reflections and intensity variations. Unlike methods that rely on a single color channel (typically green), CHROM uses a linear combination of chrominance signals that cancels out non-physiological noise while preserving the cardiac component.

The Pipeline

Why CHROM for Mobile

CHROM requires minimal compute. The entire pipeline is linear algebra operations and filtering that run comfortably on the CPU of any modern iPhone. There are no learned weights, no model files to ship, and no GPU memory pressure. In the original validation on 117 stationary subjects, CHROM achieved 92% agreement with contact PPG, with RMSE a factor of 2 better than blind source separation (BSS/ICA) methods. Under motion (stationary cycling), accuracy improved from 79% to 98% correct.

More advanced deep learning models (PhysFormer++, EfficientPhys, Dual-GAN) achieve lower error rates on benchmark datasets, but they require model files of 3.6-50MB and GPU inference. PulseProof uses CHROM as the deterministic, auditable baseline for signal extraction and layers ML classification on top for the liveness decision, keeping the signal extraction lightweight and the liveness classification accurate.

From Signal to Decision

Extracting a heartbeat signal from camera video is necessary but not sufficient for liveness verification. The extracted BVP waveform needs to be classified: is this a real, live cardiac signal from a present human, or a spoofing attempt? This is where machine learning models take over from signal processing.

PulseProof runs the entire ML inference pipeline on-device using Apple's CoreML framework. The models never see raw video. They receive the extracted signal features (BVP waveform characteristics, spectral properties, signal quality metrics) and output a binary liveness classification with a confidence score.

Model Architecture

The liveness classifier uses a lightweight temporal CNN architecture optimized for CoreML inference on the Apple Neural Engine (ANE). The model takes a fixed-length window of BVP features and processes them through 1D convolutional layers followed by a classification head.

Feature Extraction

Before the BVP waveform reaches the classifier, the signal processing layer extracts a set of features that capture the temporal, spectral, and morphological properties of the cardiac signal:

Apple Frameworks Used

Why On-Device Matters

Running ML inference on-device is not a feature choice. It is a privacy architecture decision. If PulseProof sent raw video or BVP signals to a cloud server for classification, the service would be collecting biometric health data. By keeping everything on the iPhone's Neural Engine, PulseProof processes the signal, makes the liveness decision, and discards the raw data, all before any network request is made. The only thing that leaves the device is a signed token: a yes-or-no liveness result.

Two Signals, One Human

Camera-based rPPG and Apple Watch hardware PPG measure the same physiological event (your heartbeat) through different physical modalities. The camera captures reflected light changes from facial skin. The Watch uses an LED-based optical sensor pressed against the wrist. If both signals originate from the same living person, they should be temporally correlated: the peaks and troughs of the cardiac waveform should align within a predictable propagation delay.

PulseProof exploits this correlation. When both signal sources are available, the system cross-validates them. A spoofing attack would need to simultaneously fake both a camera-visible facial pulse and a wrist-contact PPG signal, perfectly synchronized, which is dramatically harder than defeating either modality alone.

Trust Tier System

Cross-Correlation Validation

The RPPGSignalValidator module performs temporal cross-correlation between the camera-derived BVP waveform and the Watch PPG signal. Clinical validation of rPPG contactless monitoring has demonstrated Pearson correlation of 0.962 against reference PPG, with MAE of 1.061 bpm and RMSE of 2.845 bpm. A genuine living subject produces highly correlated signals (r > 0.85 typical for stationary conditions) with a predictable phase offset determined by pulse transit time (PTT). The validator checks:

Temporal alignment: The cross-correlation peak should fall within the physiologically plausible pulse transit time window (approximately 50-120ms from the aorta to the face versus the wrist). A fake signal playing back a recorded heartbeat would have arbitrary timing offset.

HRV coherence: Heart rate variability measured from both sources should match within tolerance. Real cardiac signals exhibit natural beat-to-beat variation driven by autonomic nervous system activity. A synthetic playback signal would have either too-regular or incorrectly variable timing.

Motion consistency: CoreMotion data from both devices should be consistent with a single person. Accelerometer data from the wearable is used to detect and compensate for motion artifacts in both channels. If the Watch detects walking motion but the camera face is stationary, the signals may not originate from the same person.

The Spoofing Problem

Traditional liveness detection methods based on visual appearance (face texture, depth maps, eye tracking) exist in an arms race with presentation attacks. A printed photo, a 3D-printed mask, a deepfake video on a screen: each generation of attack gets more visually convincing. Visual liveness detection is fundamentally limited because it tries to distinguish real from fake using the same modality that attackers optimize for.

rPPG-based liveness detection shifts the problem to a different domain. Instead of asking "does this look like a real face?" PulseProof asks "does this surface produce a live cardiac signal?" The answer depends on physiology, not visual fidelity.

Attack Vectors and Defenses

Physiological Impossibility

The core defense is simple: to spoof rPPG, an attacker would need to create a surface that absorbs and reflects green light in a periodic pattern that matches a real cardiac waveform, at the correct frequency (0.7-3.5 Hz), with natural HRV (beat-to-beat variation driven by autonomic nervous system), and that responds to the specific lighting conditions of the environment. This is not an engineering problem with a clever solution. It requires replicating hemodynamics.

Published research on rPPG-based presentation attack detection demonstrates detection rates exceeding 99% against standard attack types. The ISO/IEC 30107 standard for presentation attack detection (PAD) provides the testing framework PulseProof follows for evaluating anti-spoofing performance.

The Privacy Problem with Biometric Verification

Every biometric verification system faces the same tension: to prove something about a person, you typically need to collect data about that person. Face scans, fingerprints, voice prints, all of them create a biometric template that must be stored, transmitted, and protected. Data breaches of biometric databases are catastrophic because unlike passwords, you cannot reset your face.

PulseProof resolves this tension using zero-knowledge proofs. The system proves "a live human was present at this moment" without revealing any of the underlying physiological data. The verifier (your app's backend) learns exactly one bit of information: human or not human. Everything else stays on the device.

Groth16 ZK-SNARKs

PulseProof uses Groth16, a pairing-based zero-knowledge succinct non-interactive argument of knowledge (ZK-SNARK). Groth16 was chosen for three reasons:

Proof size: A Groth16 proof is constant-size (approximately 192 bytes, 3 group elements: 2 in G1, 1 in G2) regardless of the complexity of the statement being proven. This makes it practical to embed in a JWT token.

Verification speed: Server-side verification of a Groth16 proof requires three pairing operations, taking approximately 5-10ms. This is fast enough for real-time API verification.

Mobile generation: The Mopro framework (developed by PSE / Privacy and Scaling Explorations at the Ethereum Foundation) enables Groth16 proof generation on iOS devices via a Rust core with UniFFI-generated Swift bindings. On iPhone 13, Poseidon hash circuits prove in 0.05s and SHA-256 circuits in 0.76s. The witnesscalc + rapidsnark stack achieves roughly 100x speedup over arkworks-rs, and native mobile proving is up to 20x faster than browser-based snarkjs.

What the Proof Attests

The ZK circuit encodes a set of constraints that the prover (the iPhone) must satisfy. The proof attests that:

Token Assembly

The final output of the PulseProof verification flow is a signed JWT (JSON Web Token) containing:

The token is transmitted to the requesting application's backend via the PulseProof relay server. The relay is stateless: it holds the token in memory for TTL expiry and never persists biometric data. The backend verifies the ZK proof, checks the DeviceCheck attestation, validates the signature, and receives a binary result: verified or not verified.