雲端不可見的私密時間證明

非區塊鏈式多源時間證據與用戶端加密封存框架

英文題名： Cloud-Blind Private Temporal Proof: A Non-Blockchain Framework for Multi-Source Time Evidence and Client-Side Encrypted Archiving
別名： CTCL Temporal Evidence Capsule / CTCL 時間證據膠囊
作者： Neo.K（許筌崴）
機構： EveMissLab（一言諾科技有限公司），臺灣
文件編號： EML-CTCL-2026-PTP-v1.0
版本： v1.0
日期： 2026 年 7 月 28 日
文件狀態： 公開理論論文
後續文件：
1.《CTCL Temporal Evidence Capsule 技術白皮書》
2.《CTCL 私密部署與上傳規格》（限制存取）

摘要

現有數位時間證明常被簡化為「將文件雜湊寫入區塊鏈」。此方法雖能建立公開排序與難以事後修改的紀錄，卻把時間來源、資料存在、內容機密性、提交者身分、事件順序及長期保存等不同問題混為一體，並引入代幣經濟、鏈存續、交易成本與外部共識等非必要依賴。

本文提出「雲端不可見的私密時間證明」框架：原始文件在使用者控制的本地環境中完成規範化、雜湊、數位簽章與認證加密；雲端服務僅接收密文、內容承諾、時間證據與驗證中繼資料，而不取得明文或主解密金鑰。文件存在時間不由單一公鏈決定，而由多個相互獨立的時間來源、RFC 3161 時間戳權威、追加式透明日誌、硬體或軟體事件序列，以及長期證據續封共同構成。

本文將證明目標拆為五類：內容承諾、存在上界、事件順序、來源身分及長期完整性。令原始文件為 $D$ ，規範化內容為 $D_c$ ，隨機資料金鑰為 $K_D$ ，則雲端儲存的主體為：

C=\operatorname{AEAD.Enc}_{K_D}(D_c;\operatorname{AAD})

內容承諾為：

h=H(s\parallel D_c)

其中 $s$ 為私密隨機鹽值。時間戳權威只接收 $h$ ，透明日誌只記錄承諾與證據摘要，雲端物件儲存只持有 $C$ 。若解密私鑰與金鑰分片從未進入雲端執行環境，即使儲存帳戶、邊緣函式或雲端供應商本身遭到入侵，攻擊者原則上仍只能取得密文與有限中繼資料。

本文特別指出，「由雲端供應商提供靜態加密」不等於「供應商不可解密」。以 Cloudflare R2 為例，其預設靜態加密由 Cloudflare 管理金鑰；Cloudflare Access 可限制誰能取得物件，但無法取代用戶端端對端加密。若加密程式碼本身由同一雲端平台動態提供，平台被攻破時還可能注入竊取金鑰的惡意程式。因此，強安全模式必須使用本地安裝、簽章且可驗證的加密客戶端，在任何網路上傳前完成密文化。

本文最終提出「時間證據膠囊」作為可攜式證據單位，整合密文承諾、裝置序列、多來源時間區間、門檻式時間戳、透明日誌包含證明、見證者簽章與證據續封紀錄。其目的不是宣稱「數學自動產生專利權」，而是建立一份可獨立驗證、可長期保存且不暴露原文的存在與版本證據。

關鍵詞： 時間戳、用戶端加密、零知識雲端、內容承諾、RFC 3161、透明日誌、Merkle Tree、長期證據、Cloudflare R2、CTCL

一、問題的提出：時間戳並不是單一問題

「證明一份文件在某個時間以前已經存在」看似簡單，實際上至少包含下列問題：

文件內容是否自封存後未被修改？
文件最遲何時已經存在？
多個版本的先後順序為何？
是哪個裝置或身分完成封存？
時間來源是否可信？
封存服務是否可以讀取原文？
二十年後簽章與雜湊失效時，證據是否仍可驗證？
服務商倒閉、帳號被盜或基礎設施遭攻破時，證據是否仍然存在？

區塊鏈通常只提供其中一部分：

\text{承諾被寫入某個公開帳本} + \text{帳本內的相對順序}

它不自動證明：

提交者是原作者；
文件描述的事件真實發生；
區塊時間等於精確 UTC；
未公開的其他人沒有更早版本；
該文件具備專利新穎性；
原文在鏈外儲存時仍然安全。

因此，正確的研究問題不應是：

哪一條鏈最適合蓋時間戳？

而應是：

應如何把不同證明責任分離，並在不公開原文的條件下重新組合？

二、五種應被分離的證明

2.1 內容承諾

內容承諾證明：

未來揭露的文件，與當初封存的資料相同。

令規範化文件為：

D_c=\operatorname{Canonicalize}(D)

生成私密鹽值 $s$ ：

s\leftarrow\{0,1\}^{256}

內容承諾為：

h=H(s\parallel D_c)

加入私密鹽值的目的，是避免低熵或可猜測文件遭到字典比對。

承諾只證明一致性，不證明真實性。

2.2 存在時間上界

RFC 3161 時間戳權威接收資料摘要，產生帶有可信時間、唯一序號與數位簽章的時間戳權杖，用以支持「該資料最遲在某一時間已經存在」的主張。

形式上：

\tau_i = \operatorname{Sign}_{TSA_i} ( h,t_i,n_i,p_i )

其中：

$t_i$ ：時間；
$n_i$ ：唯一序號；
$p_i$ ：時間戳政策。

它不需要接收原始文件。

2.3 事件順序

即使無法立即取得可信 UTC，也可以先證明事件順序：

E_1<E_2<E_3

例如：

原始構想；
初稿；
技術規格；
公開版本；
正式申請。

事件順序可由：

單調計數器；
本地追加日誌；
TPM 或安全硬體；
前一紀錄雜湊；
簽章版本鏈；

共同建立。

令第 $k$ 筆紀錄為：

r_k = H( r_{k-1} \parallel h_k \parallel n_k \parallel m_k )

即使外部時間暫時不可用，仍可證明後一筆紀錄不能在不破壞鏈結的情況下被插入前方。

2.4 來源身分

來源證明回答：

哪個金鑰、帳號或裝置提交了這份承諾？

\sigma_U = \operatorname{Sign}_{sk_U} ( h\parallel r_k\parallel policy )

數位簽章證明控制某把私鑰的主體簽署了資料，但不能單獨證明其法律姓名、作者資格或發明人地位。

2.5 長期完整性

雜湊演算法、憑證與簽章都有生命週期。

RFC 4998 Evidence Record Syntax 提供長期存在與完整性證據的續封機制，使舊證據可在演算法或憑證老化前重新時間戳。

可表示為：

\Gamma_0 \rightarrow \tau_1(\Gamma_0) \rightarrow \tau_2(\Gamma_0,\tau_1) \rightarrow\cdots

真正的長期證據不是一次蓋章，而是一條可持續更新的證據生命週期。

三、雲端不可見的機密性模型

3.1 用戶端認證加密

產生隨機資料金鑰：

K_D\leftarrow\{0,1\}^{256}

在本地執行：

C = \operatorname{AEAD.Enc}_{K_D} ( D_c; AAD )

其中 AAD 可包含：

文件識別碼；
格式版本；
專案識別；
密碼套件；
分段索引；
不含秘密的政策資訊。

AEAD 同時提供：

機密性；
完整性；
中繼資料綁定。

雲端只收到：

(C,h,manifest,\Gamma)

而不是：

(D_c,K_D)

3.2 金鑰封裝

資料金鑰不應直接由密碼長期生成，而應隨機產生，再使用擁有者公鑰或主金鑰封裝：

W_U = \operatorname{Wrap}_{pk_U}(K_D)

若使用多裝置，可產生多個封裝：

\mathcal{W} = \{ W_{\text{desktop}}, W_{\text{hardware}}, W_{\text{recovery}} \}

雲端可保存封裝後的資料金鑰，但不能保存可解開它的私鑰。

3.3 門檻式復原

為避免單一金鑰遺失，可把復原秘密分成 $n$ 份，設定至少 $q$ 份才能復原：

K_R \rightarrow \{s_1,s_2,\ldots,s_n\}

且：

K_R = \operatorname{Recover} ( s_{i_1},\ldots,s_{i_q} )

例如 $2$ -of- $3$ ：

個人硬體金鑰；
離線紙本或加密隨身碟；
受信任第三方或公司保管份。

任何單一保管者都不能解密。

四、Cloudflare 在架構中的正確位置

Cloudflare 可以提供：

R2 物件儲存；
Workers API；
Access 存取控制；
服務權杖；
DDoS 與網路防護；
全球分發；
日誌與邊緣執行。

但它不應成為明文與解密金鑰的信任根。

Cloudflare R2 官方文件指出，R2 物件與中繼資料預設進行靜態加密，金鑰由 Cloudflare 管理。這能降低硬碟或底層儲存外洩風險，卻不構成「Cloudflare 無法解密」的密碼學保證。

Cloudflare Access 可以限制哪些使用者、群組或應用程式能存取 R2 物件，但它解決的是認證與授權，而不是在雲端控制面遭攻破時仍保持明文不可見。

因此，安全關係應為：

\text{Cloudflare} = \text{密文儲存者} + \text{存取閘道} + \text{可替換基礎設施}

而不是：

\text{Cloudflare} = \text{解密權持有者}

五、為何「在瀏覽器裡加密」仍可能不夠？

假設加密介面由 Cloudflare Pages 或 Worker 每次動態傳送 JavaScript。

若平台帳戶、供應鏈或邊緣程式遭攻破，攻擊者可以替換前端程式，使其在加密前竊取：

明文；
密碼；
私鑰；
恢復分片。

因此，即使演算法本身正確：

\text{惡意加密客戶端} \Rightarrow \text{端對端機密性失敗}

5.1 強安全模式

強模式應使用：

本地安裝的桌面應用程式；
簽章 CLI；
可重現建置；
離線加密；
固定版本；
發布簽章與雜湊驗證；
加密完成後才開啟網路上傳。

工作流程：

D \overset{\text{offline client}}{\longrightarrow} (C,h,\Gamma) \overset{\text{network}}{\longrightarrow} Cloud

明文永不跨越本地信任邊界。

5.2 便利模式

瀏覽器模式可以提供較佳使用體驗，但安全聲明必須降低：

在服務端與前端發布管線未遭攻破的前提下，服務商不保存解密金鑰。

不能把它宣稱為對平台完全零信任。

六、多來源時間區間

單一裝置時間可能被修改；單一 NTP 來源可能發生延遲、錯誤或攻擊。

RFC 8915 的 Network Time Security 使用 TLS 與 AEAD 保護 NTP 用戶端—伺服器模式的身分與訊息認證，但網路延遲仍使時間具有不確定性。

因此，證據應記錄時間區間：

T= [t_{\min},t_{\max}]

而不是假裝得到無誤差的瞬間。

對多個來源：

\mathcal{T} = \{ T_1,T_2,\ldots,T_n \}

可取相容交集：

T^{*} = \bigcap_{i\in Q}T_i

其中 $Q$ 是符合信任政策的來源集合。

若來源彼此衝突，系統不應強行生成單一時間，而應保存衝突證據。

七、門檻式時間戳

單一 TSA 可能：

金鑰遭竊；
時鐘錯誤；
停止服務；
被司法命令影響；
在未來失去信任。

因此，可要求 $q$ -of- $n$ 個獨立 TSA：

\operatorname{ValidTime} \iff \sum_{i=1}^{n} \mathbf{1} [ \operatorname{Verify}(\tau_i)=1 ] \ge q

並要求：

不同營運者；
不同憑證鏈；
不同司法管轄；
可接受的時間差；
明確的時間政策。

這不是要求全球共識，而是建立有限、可審核的信任分散。

八、透明日誌而非金融型區塊鏈

追加式透明日誌使用 Merkle Tree 建立：

包含證明；
一致性證明；
簽章檢查點；
公開監督。

Sigstore Rekor 是此類架構的實例：提交者可查詢包含證明，審計者可檢查日誌是否維持追加式歷史，紀錄是否被修改或刪除。

令葉節點為：

\ell_k = H( h_k \parallel evidence\_digest_k \parallel policy_k )

雲端或公共日誌無須知道文件內容。

透明日誌的目標不是讓所有節點對貨幣狀態達成共識，而是：

\boxed{ \text{讓任何偷偷改寫歷史的行為，留下可被比較的矛盾證據。} }

九、CTCL Temporal Evidence Capsule

每次封存產生一個可攜式膠囊：

\Gamma = ( V, H, C, W, S, T, L, R, P )

其中：

$V$ ：格式版本；
$H$ ：內容承諾；
$C$ ：密文描述與分段摘要；
$W$ ：資料金鑰封裝；
$S$ ：提交者與裝置簽章；
$T$ ：多來源時間證據；
$L$ ：透明日誌證明；
$R$ ：長期續封鏈；
$P$ ：證據與隱私政策。

概念結構如下：

{
  "type": "CTCL-Temporal-Evidence-Capsule",
  "version": "1.0",
  "content_commitment": {
    "algorithm": "SHA-512",
    "digest": "...",
    "salt_storage": "owner-only"
  },
  "ciphertext": {
    "aead_suite": "...",
    "object_digest": "...",
    "segments": 1
  },
  "key_envelopes": [
    {
      "recipient": "owner-device",
      "wrapped_key": "..."
    }
  ],
  "sequence": {
    "record_index": 1847,
    "previous_record": "...",
    "device_signature": "..."
  },
  "trusted_time": {
    "interval_start": "...",
    "interval_end": "...",
    "tokens": ["..."]
  },
  "transparency": {
    "log_id": "...",
    "leaf_index": 481931,
    "inclusion_proof": ["..."]
  },
  "renewal_chain": []
}

此 JSON 只是概念表示；正式欄位、序列化、演算法協商與驗證規則將在技術白皮書中定義。

十、威脅模型

10.1 雲端物件外洩

攻擊者取得 R2 中全部物件。

可取得：

密文；
部分中繼資料；
內容承諾；
封裝金鑰；
時間證據。

若 AEAD 與金鑰管理安全，不能取得明文。

10.2 Cloudflare 帳戶遭接管

攻擊者可以：

刪除或替換密文；
取得 API 權限；
修改 Worker；
阻止存取；
收集中繼資料。

但若本地保存證據膠囊與外部時間戳，替換會被摘要驗證發現；若金鑰不在 Cloudflare，帳戶接管本身不應直接解密既有文件。

10.3 Cloudflare 平台本身遭攻破

強模式的安全目標是：

\operatorname{Compromise}(Cloudflare) \not\Rightarrow \operatorname{Recover}(D)

前提包括：

明文未上傳；
主私鑰未進入 Worker、Secrets 或 R2；
客戶端不是從遭攻破的平台即時下載；
密碼學實作未受破壞；
使用者裝置未遭入侵。

10.4 惡意 Worker

Worker 只能處理：

密文上傳；
承諾登記；
時間戳轉送；
日誌提交；
存取控制。

它不應具有：

解密函式；
主私鑰；
復原金鑰；
可還原明文的密碼；
原始文件暫存。

10.5 用戶端遭攻破

這是最嚴重的風險之一。

若攻擊者控制：

作業系統；
加密程式；
鍵盤；
記憶體；
硬體金鑰使用流程；

則可能在加密前取得明文或在解密時取得金鑰。

雲端零知識不能補救已遭控制的端點。

10.6 金鑰遺失

真正不可由服務商解密的系統，也意味服務商無法替使用者恢復遺失的唯一金鑰。

因此必須在：

\text{不可代解}

與：

\text{可復原性}

之間透過門檻分片取得平衡。

10.7 中繼資料洩漏

即使內容加密，仍可能洩漏：

上傳時間；
檔案大小；
版本頻率；
IP 與帳號；
專案數量；
存取行為；
收件者或金鑰識別。

未來可透過：

固定分段大小；
填充；
延遲批次上傳；
匿名化承諾；
分離身分與儲存帳號；

降低洩漏，但無法完全消除。

10.8 未來密碼學失效

量子計算、演算法弱點或金鑰長度不足，可能使長期密文與證據失效。

系統應支援：

密碼套件版本化；
重新封裝資料金鑰；
重新加密；
證據續封；
多演算法承諾；
後量子遷移。

十一、安全命題

命題一：供應商不可見性

若：

$K_D$ 由安全隨機源生成；
AEAD 達到預期機密性；
解密私鑰未進入供應商系統；
客戶端在供應商信任邊界外完成加密；

則僅取得雲端儲存與控制面的攻擊者，不能有效恢復 $D$ 。

命題二：存在上界而非創作時間

有效 RFC 3161 權杖可支持：

D_c \text{ 的承諾最遲在 }t_i\text{ 已存在}

但不能證明：

D_c \text{ 正好在 }t_i\text{ 創作}

命題三：簽章不等於作者資格

\operatorname{Verify}(\sigma_U)=1

只證明對應私鑰簽署該承諾，不能單獨證明簽署者是法律上的發明人或著作人。

命題四：透明不等於真實

透明日誌可證明紀錄被追加及未被無痕改寫，不能證明紀錄所描述的外部事件真實。

命題五：雲端加密不等於端對端加密

若服務商管理解密金鑰，或明文在服務商執行環境中出現，則：

\text{Encryption at Rest} \not\Rightarrow \text{Provider-Blind Confidentiality}

十二、與區塊鏈方案的比較

面向	公鏈時間戳	私有區塊鏈	CTCL 多源時間證據
是否需要代幣	通常需要或依賴鏈經濟	不一定	不需要
原文隱私	視鏈外設計	視設計	預設本地加密
時間精度	區塊級、受協議影響	依節點	可記錄來源與不確定區間
信任來源	共識與經濟安全	聯盟節點	TSA、時間源、日誌、見證分層
長期續封	非原生	視設計	原生證據生命週期
服務商被攻破	依鏈外金鑰	依聯盟	僅雲端受損不應解密
法律整合	司法管轄而異	需額外設計	可選配合格 TSA／公證
驗證成本	需鏈資料或節點	需聯盟服務	可攜膠囊離線驗證
能源與金融依賴	可能較高	較低	低
證明責任分離	常被混合	可分離	明確分層

本文不是主張區塊鏈毫無價值，而是指出：

\boxed{ \text{當目標是私密存在證明時，} \text{金融型全球共識通常不是必要條件。} }

十三、法律與專利邊界

時間證據可以協助證明：

某份內容在某時間以前存在；
某版本與另一版本的順序；
某金鑰曾簽署該內容；
封存後內容未被修改；
某些第三方曾見證其承諾。

它不能自動建立：

專利權；
新穎性；
進步性；
發明人資格；
商業秘密管理已盡合理措施；
法院必然採信；
他人沒有更早紀錄。

因此，CTCL 應被定位為：

\boxed{ \text{防禦性證據與時間來源基礎設施} }

而不是：

\boxed{ \text{自動取得智慧財產權的機器} }

正式專利申請、保密契約、公證、律師證據保全及營業秘密管理仍具有不可替代性。

十四、公開、技術與私密三層文件

CTCL 應採用三層知識發布結構。

14.1 公開理論論文

公開：

問題定義；
理論模型；
信任邊界；
證據類型；
非區塊鏈理由；
社會與法律意義。

不公開：

正式網域；
帳號結構；
金鑰分片位置；
管理員流程；
私密存取路徑；
完整防禦策略。

14.2 公開或半公開技術白皮書

公開：

模組架構；
證據膠囊格式；
API 原則；
驗證流程；
威脅模型；
密碼套件選擇；
部署範例。

仍抽象化：

生產環境權杖；
實際帳號識別；
復原持有人；
私密 Bucket 名稱；
真實密鑰與私有端點。

14.3 私密部署與上傳規格

限制存取：

真實 Cloudflare 帳號與資源；
網域與路由；
R2 Bucket；
Worker 及 Access 政策；
金鑰管理與復原；
管理員操作；
事故應變；
生產環境驗證資料。

私密部署文件本身亦應先由本地客戶端加密，再上傳至雲端。

十五、後續技術路線

階段一：最小可驗證封存

本地文件規範化；
私密鹽值內容承諾；
用戶端 AEAD；
擁有者公鑰封裝；
本地 Ed25519 或等價簽章；
單一 RFC 3161；
R2 密文儲存；
離線驗證 CLI。

階段二：多源證據

多 TSA；
NTS 時間區間；
追加式 Merkle 日誌；
外部 checkpoint；
裝置事件序列；
證據膠囊匯出。

階段三：長期與組織化

RFC 4998 式續封；
2-of-3 金鑰復原；
硬體金鑰；
多見證者；
密碼演算法遷移；
法律時間戳或公證選配。

階段四：時間信任聯邦

大學；
研究機構；
公司；
檔案館；
獨立見證者；

共同簽署透明日誌檢查點，但不持有文件明文或完整解密金鑰。

十六、研究限制

16.1 無法消除端點風險

使用者裝置被控制時，本地加密也可能失效。

16.2 無法完全隱藏中繼資料

流量與物件模式可能暴露行為資訊。

16.3 多來源並非無條件可信

TSA、時間源與見證者仍可能共謀或共享供應鏈。

16.4 密碼學安全具有時間性

演算法必須持續更新。

16.5 私密性與復原性存在張力

越接近真正不可代解，越難在使用者遺失金鑰後恢復。

16.6 法律效果依司法管轄而異

技術證明與法律推定必須分開。

十七、核心命題整理

命題一：證明責任分離

\text{時間} \neq \text{存在} \neq \text{身分} \neq \text{真實} \neq \text{權利}

命題二：用戶端優先

\text{明文不進入雲端} \Rightarrow \text{雲端供應商可被降格為密文保管者}

命題三：供應商攻破隔離

\operatorname{Compromise}(Cloud) \not\Rightarrow \operatorname{Decrypt}(Document)

前提是私鑰與可信客戶端獨立於雲端。

命題四：多源時間

\text{可信時間} = \text{來源身分} + \text{訊息認證} + \text{不確定區間} + \text{交叉驗證}

命題五：非金融透明

追加式透明日誌可提供公開可監督歷史，而不需要代幣與金融共識。

命題六：長期續封

一次時間戳不是永久證據；證據必須能在密碼學老化前續封。

命題七：可攜式驗證

有效證據應能離開原服務商後獨立驗證。

十八、結論：不是把秘密交給更強的雲，而是讓雲永遠只看見密文

數位封存常將安全理解為：

選擇一家足夠強、足夠可信、足夠難被攻破的雲端公司。

但任何服務商都可能遭遇：

帳號接管；
供應鏈漏洞；
內部濫權；
法律命令；
程式錯誤；
未來密碼學失效；
組織與商業變動。

因此，更合理的設計不是宣稱：

\text{只要Cloudflare不被攻破，文件就安全}

而是把安全目標提高為：

\boxed{ \text{即使Cloudflare被攻破，} \text{攻擊者仍無法只靠雲端資料解密文件。} }

這要求：

明文在本地規範化；
本地產生隨機資料金鑰；
本地完成認證加密；
解密私鑰不進入雲端；
時間服務只接收內容承諾；
透明日誌只記錄證據摘要；
雲端只保管密文；
證據膠囊可離線匯出；
長期證據持續續封；
復原權分散而不集中於服務商。

本文最終提出：

CTCL Temporal Evidence Capsule

CTCL 時間證據膠囊

其核心不是一個更華麗的時間戳，而是：

\boxed{ \text{私密內容承諾} + \text{多來源可信時間} + \text{追加透明歷史} + \text{可攜式長期證據} }

最精簡的對外表述是：

Not merely a timestamp, but a cloud-blind, verifiable temporal provenance system.

不是單純時間戳。

而是一套雲端不可見、可獨立驗證的時間來源與歷史證明系統。

參考文獻

Adams, C., Cain, P., Pinkas, D., and Zuccherato, R. “Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP).” RFC 3161, IETF, 2001.
Gondrom, T., Brandner, R., and Pordesch, U. “Evidence Record Syntax (ERS).” RFC 4998, IETF, 2007.
Franke, D., Sibold, D., Teichel, K., Dansarie, M., and Sundblad, R. “Network Time Security for the Network Time Protocol.” RFC 8915, IETF, 2020.
Cloudflare. “R2 Data Security.” Cloudflare Developer Documentation, updated 2026.
Cloudflare. “Protect an R2 Bucket with Cloudflare Access.” Cloudflare Developer Documentation, updated 2026.
Cloudflare. “Use Server-Side Encryption with Customer-Provided Keys (SSE-C).” Cloudflare Developer Documentation, updated 2026.
Sigstore. “Rekor Transparency Log Overview.” Sigstore Documentation.
Sigstore. “Security Model and Threat Model.” Sigstore Documentation.
Haber, S., and Stornetta, W. S. “How to Time-Stamp a Digital Document.” Journal of Cryptology, 3, 1991, pp. 99–111.
Merkle, R. C. “A Digital Signature Based on a Conventional Encryption Function.” CRYPTO ’87.
Menezes, A., van Oorschot, P., and Vanstone, S. Handbook of Applied Cryptography. CRC Press, 1996.
NIST. Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, SP 800-38D.
Bonneau, J., et al. “SoK: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies.” IEEE Symposium on Security and Privacy, 2015.
Laurie, B., Langley, A., and Kasper, E. “Certificate Transparency.” RFC 6962, IETF, 2013.
Crosby, S. A., and Wallach, D. S. “Efficient Data Structures for Tamper-Evident Logging.” USENIX Security Symposium, 2009.

建議引用格式

Neo.K（許筌崴）。（2026）。〈雲端不可見的私密時間證明：非區塊鏈式多源時間證據與用戶端加密封存框架〉。EveMissLab，EML-CTCL-2026-PTP-v1.0，未發表研究手稿。

雲端不可見的私密時間證明_非區塊鏈式多源時間證據與用戶端加密封存框架_v1.0

雲端不可見的私密時間證明

非區塊鏈式多源時間證據與用戶端加密封存框架

摘要

一、問題的提出：時間戳並不是單一問題

二、五種應被分離的證明

2.1 內容承諾

2.2 存在時間上界

2.3 事件順序

2.4 來源身分

2.5 長期完整性

三、雲端不可見的機密性模型

3.1 用戶端認證加密

3.2 金鑰封裝

3.3 門檻式復原

四、Cloudflare 在架構中的正確位置

五、為何「在瀏覽器裡加密」仍可能不夠？

5.1 強安全模式

5.2 便利模式

六、多來源時間區間

七、門檻式時間戳

八、透明日誌而非金融型區塊鏈

九、CTCL Temporal Evidence Capsule

十、威脅模型

10.1 雲端物件外洩

10.2 Cloudflare 帳戶遭接管

10.3 Cloudflare 平台本身遭攻破

10.4 惡意 Worker

10.5 用戶端遭攻破

10.6 金鑰遺失

10.7 中繼資料洩漏

10.8 未來密碼學失效

十一、安全命題

命題一：供應商不可見性

命題二：存在上界而非創作時間

命題三：簽章不等於作者資格

命題四：透明不等於真實

命題五：雲端加密不等於端對端加密

十二、與區塊鏈方案的比較

十三、法律與專利邊界

十四、公開、技術與私密三層文件

14.1 公開理論論文

14.2 公開或半公開技術白皮書

14.3 私密部署與上傳規格

十五、後續技術路線

階段一：最小可驗證封存

階段二：多源證據

階段三：長期與組織化

階段四：時間信任聯邦

十六、研究限制

16.1 無法消除端點風險

16.2 無法完全隱藏中繼資料

16.3 多來源並非無條件可信

16.4 密碼學安全具有時間性

16.5 私密性與復原性存在張力

16.6 法律效果依司法管轄而異

十七、核心命題整理

命題一：證明責任分離

命題二：用戶端優先

命題三：供應商攻破隔離

命題四：多源時間

命題五：非金融透明

命題六：長期續封

命題七：可攜式驗證

十八、結論：不是把秘密交給更強的雲，而是讓雲永遠只看見密文

CTCL Temporal Evidence Capsule

CTCL 時間證據膠囊

參考文獻

建議引用格式