Temporal Blockchain: Secure Offline Operation
Temporal Blockchain: Secure Offline Operation
This document specifies the secure offline operational mode of the Temporal Blockchain System, enabling Temporal Mining Nodes (TMNs) to continue generating verifiable timestamps and process a limited set of transactions even without network connectivity. This capability is critical for high-security environments, disaster recovery scenarios, and applications requiring continuous operation in disconnected settings.
1. Overview
The offline operation mode leverages the TMNs’ hardware-secured timekeeping capabilities and pre-shared cryptographic material to maintain temporal integrity and security without relying on external network synchronization. Key features include:
- Hardware-Based Timekeeping: The TMN’s chip-scale atomic clock (CSAC) and temperature-compensated crystal oscillator (TCXO) provide a stable and accurate time source, even in the absence of GNSS signals.
- Pre-Shared Initialization Vectors: Before going offline, the TMN receives a set of cryptographically secure, time-based initialization vectors from the network. These vectors are used to verify the authenticity of offline timestamps.
- Drift Compensation: Advanced algorithms compensate for the inherent drift of the atomic clock, maintaining accuracy over extended offline periods.
- Limited Transaction Processing: Offline TMNs can process a limited set of pre-approved transaction types (e.g., those related to a dead man’s switch or other pre-configured contingencies).
- Secure Re-synchronization: When network connectivity is restored, the TMN securely re-synchronizes with the network, submitting any offline-generated timestamps and transactions for verification.
2. Pre-Shared Initialization Vectors
Before a TMN goes offline, it must obtain a set of pre-shared initialization vectors from the network. These vectors are cryptographically bound to the current consensus time and the TMN’s identity, enabling secure verification of offline timestamps.
Format: An initialization vector (IV) consists of:
timestamp: The consensus time at which the vector was generated (hardware-verified).random_value: A cryptographically secure random value.hmac: An HMAC (Hash-based Message Authentication Code) of thetimestampandrandom_value, signed by a quorum of online TMNs.
Generation: Initialization vectors are generated by the network (or a designated subset of online TMNs) upon request from a TMN preparing to go offline. The process involves:
- The requesting TMN generates a request containing its public key and the current consensus time.
- Online TMNs receive the request and independently generate a random value.
- Each online TMN creates an IV, including the timestamp, the random value, and an HMAC calculated using a shared secret key (or derived from a threshold signature scheme).
- The IVs are returned to the requesting TMN.
Storage: The requesting TMN securely stores the set of initialization vectors in its Hardware Security Module (HSM).
Validity Period: Each set has an expiration; after that, the Node must re-connect to get a refreshed pool of data.
3. Drift Compensation
Atomic clocks, while highly accurate, exhibit a small amount of drift over time. The offline operation mode employs drift compensation algorithms to minimize the impact of this drift.
Algorithm: Kalman filtering (or a similar algorithm) is used to model and predict the clock drift. The Kalman filter uses:
- Prior Drift Measurements: Before going offline, the node takes several measurements over a duration.
- Environmental Factors: The algorithm may take into account temperature variations, as these can affect clock drift. Temperature sensors within the TMN provide input for this.
- Clock Characteristics: Stored models from manufacturer for how the components respond to those effects (temperature, etc.)
Parameters: The Kalman filter parameters (e.g., process noise, measurement noise) are determined during a calibration phase when the TMN is online and can compare its clock to the consensus time. These parameters, just as any measurement, use hardware attestation as part of their derivation and signing steps.
Update: While offline, the TMN continuously updates its drift estimate based on the Kalman filter model.
Drift Estimate Data Storage: This data also gets attached with any output from the system so that the mainnet validators can do independent assessment and thus incorporate this with other scoring for ranking nodes.
4. Offline Timestamp Generation
When a TMN generates a timestamp while offline, it performs the following steps:
- Time Retrieval: The STPU retrieves the current time from the CSAC.
- Drift Correction: The STPU applies the drift compensation algorithm to adjust the time based on the estimated clock drift.
- Initialization Vector Selection: The STPU selects the next unused initialization vector from the pre-shared set.
- Timestamp Creation: The STPU creates a timestamp containing:
- The drift-corrected time.
- The index of the initialization vector used.
- A status code indicating Offline.
- Cryptographic Attestation: The STPU generates a cryptographic signature of the timestamp using the TMN’s private key. The signature incorporates the selected initialization vector, linking the timestamp to the pre-shared cryptographic material.
5. Offline Timestamp Verification
When an offline-generated timestamp is presented to an online node (after the TMN has reconnected to the network), the online node performs the following verification steps:
- Initialization Vector Retrieval: The online node retrieves the initialization vector corresponding to the index included in the timestamp.
- HMAC Verification: The online node verifies the HMAC of the
timestampandrandom_valuein the initialization vector, using the shared secret key (or the public keys of the signing TMNs). This confirms that the initialization vector is authentic and was generated by the network. - Timestamp Signature Verification: The online node verifies the cryptographic signature of the timestamp using the offline TMN’s public key.
- Drift Range Check: The node computes a likely/possible range (max, min) for that device based on known characteristics.
- Liveness Check. That vector hasn’t been used previously.
If all verifications are successful, the online node can be confident that the timestamp was generated by the specified TMN while it was offline and that the time is accurate within the bounds of the clock drift and the initialization vector’s validity period.
6. Limited Transaction Processing
While offline, a TMN can process a limited set of pre-approved transaction types. This restriction is necessary to prevent double-spending and other attacks that could exploit the lack of network connectivity.
Allowed Transactions:
- Dead Man’s Switch Activation: Transactions that trigger a pre-configured action (e.g., releasing data, transferring assets) if the TMN remains offline for a specified period.
- Pre-Signed Transactions: Transactions that were signed by authorized parties before the TMN went offline. These transactions have pre-defined conditions and execution parameters.
- Emergency Messages: High-priority messages (with limited size and frequency) that can be broadcast once the TMN reconnects to the network.
- Time-Stamped Attestations (no transfer of value).
Prohibited Transactions:
- Standard currency transfers.
- Smart contract interactions that modify the global state (except for pre-approved dead man’s switch actions).
- Any transactions that introduce a double spending risk.
Storage: Offline transactions are stored securely in the TMN’s HSM until network connectivity is restored.
Reconciliation: When the TMN reconnects to the network, it submits its stored offline transactions for validation and inclusion in the blockchain.
7. Secure Re-synchronization
When a TMN reconnects to the network, it undergoes a secure re-synchronization process:
- Time Synchronization: The TMN synchronizes its clock with the consensus time, using the standard PoTA protocol.
- Initialization Vector Update: The TMN obtains a new set of pre-shared initialization vectors.
- Offline Transaction Submission: The TMN submits any stored offline transactions for validation and inclusion in the blockchain.
- State Update: The TMN downloads any missed blocks and updates its state to match the current blockchain state.
8. Security Analysis
Time Manipulation: The combination of hardware-secured timekeeping, drift compensation, and pre-shared initialization vectors makes it extremely difficult to manipulate the time while offline. An attacker would need to compromise the TMN’s HSM, the atomic clock, and the pre-shared cryptographic material.
Replay Attacks: Initialization vectors can only be used once, preventing replay attacks where an attacker tries to reuse an old timestamp.
Drift Estimate Tampering: This offline data gets checked on reconnect, for extreme or suspicious changes to values; if identified, triggering further investigation.
Double-Spending: The restriction on transaction types prevents double-spending while offline.
Compromised Initialization Vectors: If an attacker gains access to the pre-shared initialization vectors, they could potentially forge offline timestamps. However, the validity period of the vectors limits the duration of such an attack. Additionally, those vectors are tied to a single unique node’s ID.
Physical Tampering: The TMN’s tamper-resistant hardware protects against physical attacks.