Clock Synchronization and System Time Source

Effective: March 17, 2026 · DCF-421/422/423/424

1. Purpose

This document defines H33.ai's clock synchronization standards in accordance with ISO 27001 A.8.17 (Clock Synchronization). Accurate and consistent timestamps across all systems are essential for audit trail integrity, log correlation, security event investigation, and cryptographic operations.

For H33.ai specifically, clock accuracy is critical because the production authentication pipeline relies on precise timestamps for Dilithium signature attestation, STARK proof generation, and authentication audit trails that must be legally defensible.

2. Authoritative Time Source

Amazon Time Sync Service was selected as the sole NTP source because it provides stratum 1 accuracy without requiring internet connectivity (accessible via link-local address), is available to all EC2 instances at no additional cost, and is maintained by AWS with redundant GPS and atomic clock references across multiple facilities.

3. System Configuration

EC2 Instances (Graviton4 c8g.metal-48xl)

All production EC2 instances, including the Graviton4 c8g.metal-48xl benchmark and compute hosts (192 vCPUs, 377 GiB), use chrony configured with Amazon Time Sync as the sole NTP source. The configuration ensures:

• Only the Amazon Time Sync endpoint (169.254.169.123) is configured as an NTP server. No public NTP pools are used.
• chrony is set to start at boot via systemd, ensuring time synchronization begins immediately on instance launch.
• The makestep directive allows an initial large time correction on boot, then restricts subsequent adjustments to gradual slewing.
• The iburst option enables rapid initial synchronization (4 requests in the first 2 seconds).

RDS PostgreSQL Instances

Amazon RDS is a managed service. Clock synchronization for RDS instances is handled automatically by AWS infrastructure. No customer configuration is required or possible. AWS guarantees that RDS instances are synchronized to Amazon Time Sync Service.

ElastiCache Redis

Amazon ElastiCache is a managed service. Clock synchronization is handled automatically by AWS. Redis TTL operations and expiry timestamps are consistent with the NTP-synchronized system clock.

Auth1 (Elastic Beanstalk)

Auth1 runs on Elastic Beanstalk, which provisions EC2 instances using Amazon Linux. These instances use Amazon Time Sync Service by default via chrony. No additional configuration is required. JWT token expiration timestamps, OTP validity windows, and authentication event timestamps all derive from the synchronized system clock.

4. Logging and Timestamp Standards

All log timestamps across H33.ai's infrastructure use the following standards:

• Timezone: All timestamps are recorded in UTC (Coordinated Universal Time). No local timezone offsets are used in log records.
• Format: ISO 8601 format (e.g., 2026-03-17T14:30:00.000Z) for application logs. AWS services use their native timestamp formats, all in UTC.
• Correlation: Synchronized clocks across all systems enable reliable cross-service log correlation. A security event can be traced from CloudFront access log, through Auth1 application log, to RDS query log with consistent timestamps.

Services and their timestamp synchronization:

5. Importance for H33 Cryptographic Operations

Clock accuracy is particularly critical for H33.ai's post-quantum authentication pipeline:

• Dilithium signature attestation: Each 32-user FHE batch is attested with a single ML-DSA (Dilithium) signature that includes a timestamp. Clock skew would invalidate signature verification or create ambiguous audit trails.
• STARK proof generation: ZKP STARK proofs include temporal metadata used for cache key generation in the in-process DashMap. Clock inconsistencies could cause cache misses or stale proof validation.
• Authentication audit trails: Per-authentication timestamps (38.5 µs per auth at 2.17M auth/sec sustained) must be monotonically increasing and correlatable across batch boundaries for forensic analysis.
• JWT token expiration: Auth1 JWT tokens have precise expiration timestamps. Clock skew between token issuance (Auth1 on EB) and token validation (client applications) could cause premature expiration or validation failures.

6. Monitoring and Alerting

• NTP offset monitoring: DataDog monitors the chrony NTP offset on all EC2 instances. An alert is triggered if the clock skew exceeds 100 milliseconds from the reference source.
• chrony status checks: Automated health checks verify that chrony is running and synchronized on all instances. Instance health check failures trigger auto-replacement via Auto Scaling Groups.
• Stratum monitoring: Alerts fire if any instance reports a stratum value greater than 3, indicating potential loss of synchronization chain integrity.

7. Verification

Clock synchronization status can be verified on any EC2 instance using the following commands:

• chronyc tracking — Shows current synchronization status, reference source, stratum, and offset.
• chronyc sources -v — Displays configured NTP sources and their polling status.
• timedatectl — Confirms that the system clock is synchronized and NTP is active.

Expected output confirms: Reference ID pointing to 169.254.169.123, stratum 1 or 2, and offset in microseconds (not milliseconds).

8. Review Schedule

• Continuous: DataDog monitors NTP offset and chrony status in real-time with automated alerting.
• Annual: CISO reviews clock synchronization configuration, verifies chrony settings across all instance types, and confirms that monitoring thresholds remain appropriate.
• On infrastructure change: Any new EC2 instance type, region, or managed service deployment triggers a verification of clock synchronization configuration.