【中鋼AI現場1：1千5百度高熱密閉生產環境如何監控？】高爐AI應用大剖析

中鋼靠間接量測高爐生產數據，一步步打開黑盒子，運用AI即時監控爐況，提早預測異常生產狀況即時應變

文/翁芊儒 | 2021-03-04發表
攝影／洪政偉

高爐之於鋼廠，是不可或缺的一環。飄洋渡海的鋼鐵原料從港口上岸後，會先由煉焦工廠製成焦炭、燒結工廠製成燒結礦與鐵礦，加入其他次要原料後，就會來到鋼鐵融煉的第一站，高爐。

高爐的作用，就是透過一連串高溫熔融反應，將鋼鐵原料煉成鐵水。雖然說起來容易，實際上，高爐卻是一個複雜的煉鐵反應器。中鋼煉鐵廠高爐二課課長許雍達解釋，每一座高爐，都集合了非常多系統於一身，包括了爐體本身冷卻系統、熱風爐、原料輸送、出鐵、爐氣處理、頂壓回收發電、噴媒等環節，每個系統互相搭配，才能維持高爐穩定運作。

這個系統中，真正煉製鐵之處，就是外觀形似巨大養樂多瓶的高爐爐身。其運作原理，是從上方加入煉鐵原料，以一層焦炭、一層燒結礦與鐵礦的方式，盡量將原料均勻散布其中，再透過周邊的熱風爐，將空氣加熱，從高爐下部的鼓風嘴鼓進高爐，來加熱、還原，將鐵礦石融煉成鐵水與爐渣。

熔煉過程中，中鋼也透過鼓風嘴噴吹粉煤，來取代部分焦炭作為還原劑，可降低煉焦爐的負荷，並有利於爐熱調節；而爐內產生的高爐氣，也能在淨化後用來發電，並作為熱風爐及廠內的燃料，來達成節能、減少碳排放的效益。最後的鐵水與爐渣，則會分開取出，各自進行下一步的加工或販售。

許雍達指出，這套高爐生產的做法，早從十多年前就持續運作至今，但在過去，高爐內部高溫、密閉且不易觀測，難以得知爐況是否符合預期，「比如原料一層一層加入之後，到底分佈均不均勻？又要如何在爐溫下降之前，提早預測來因應？」

這些問題，隨著IoT與AI技術日漸成熟，中鋼開始蒐集更多生產數據，逐步翻轉過去熟悉的高爐運行操作。

落地27項高爐智慧應用，更即時掌握高爐生產動態

中鋼約從3年前開始，致力於研發高爐AI，不只開發高爐爐況監控的相關應用，也開發周邊設備的AI應用，比如原料輸送帶的預測維修、熱風爐生產效率與耗能監控、現場人員的安全監控等，截至今年初，已經完成27項高爐智慧應用的開發，依據應用的特性與適用場域，分散部署在4座高爐中。

由於高爐本身就像是一個黑盒子，為了掌握高爐的生產狀況，中鋼在高爐上裝設了多種感測器，就是要靠各種生產數據，一步步將盒子打開。

比如說，從高爐上方布料時，雖然是均勻旋轉布料，但實際布料情況還是會依據爐內氣流變化而改變，為了監控布料狀況並適時調整，中鋼在布料槽裝設了料面溫度儀與輪廓儀，來掌握布料形狀與高溫氣體的分布情形。在爐壁上，中鋼也裝測了溫度感測器，透過爐壁溫度變化頻率，來預測爐壁冷卻元件是否受侵蝕、內部是否結塊。

不只如此，為了預測爐熱變化，中鋼量測出鐵口的鐵水溫度變化，參考操作條件、鐵渣的化性分析，開發AI預測未來爐熱；也運用爐溫爐壓分布的異常數值，找出發生管道流異常的可能性。透過更即時發現異常並自動預警，就是要讓產線人員盡早發現問題，才能提前調整生產參數來因應。

而且，針對所有開發的生產數據監控與AI應用，中鋼開發了綜合爐況評分機制，能從原料分佈、氣流狀況、目前風量、鐵水產量、爐內溫度等生產狀況，為高爐當下的運行表現評分，讓產線人員可以更直覺、快速地的了解當前高爐爐況，「中鋼自己設定的目標，是要隨時大於89分以上，」許雍達說。

克服AI落地挑戰，中鋼導入一站式生產數據監控平臺

中鋼過去開發AI應用時，是由技術人員設法取得生產數據，開發出AI模型，再由IT單位開發成應用程式，個別部署到現場中控室的單機電腦中。

許雍達指出，這個做法面臨了三大挑戰。首先，當時從生產環境蒐集到的資料，位於封閉式的生產系統中，為避免透過外部線路存取資料時，可能帶來的資安風險，「研究人員不能輕易的取得生產數據資料，分析費時費力。」

再加上，每一支開發完成的應用程式，都必須部署到中控室的單機電腦中，透過視窗介面來呈現，在應用程式分散在多臺電腦的情況下，增加了電腦、網路的維護工作。不只如此，隨著蒐集到的資料量更大，AI分析也需要更大量的硬體運算需求，原有的主機資源逐漸不敷使用。

這三大挑戰，讓中鋼在2019年底，率先在二號高爐場域，規劃建置AIoT智慧分析平臺，更找來研究部門、子公司中冠資訊共同研發，利用二號高爐在去年大修的期間，同步導入該場域。

這套AIoT平臺最主要的目的，是要將分散部署在不同電腦的AI應用，整合到同一個Ｗeb平臺中，讓員工只要以瀏覽器開啟入口網站，登入帳密，就能一站式管理高爐所有的生產資訊。

建置過程中，中鋼不只以Web介面重新設計AI應用儀表板，也將過去難以取得的生產數據整合到一個資料平臺，供技術人員更方便的分析取用資料，更建置了專屬AI應用的硬體資源，取代分散部署到電腦主機的方法。

許雍達指出，AIoT平臺上線後，中控人員不只能即時查看重要的生產資訊，當高爐發生任何異常狀況，平臺也會自動觸發告警，並顯示操作指引，讓員工可以依照指示排除異常，將異常狀況可能帶來的傷害降到最低。

比如說，當AI偵測到四號高爐的爐身發生結塊，就能利用過去一段時間的溫度變化，去推測結塊情形的演變，系統也會提供操作指引，來建議員工應使用哪一種應對模式，才不會導致結塊問題更嚴重。

處置完成後，員工也可以直接在介面中回報，將此次事故處理過程提交出去，作為歷史維運紀錄，而且，過去類似事故的處理方法與結果，也會同步附件於操作指引的介面中，提供緊急處理時參閱。

除了上線網頁版的AIoT監控平臺，中鋼也接續打造了行動裝置版本，只要安裝到手機上，具登入權限的中控人員，就能隨時隨地掌握生產即時動態，了解異常狀態資訊。

今年初，二號高爐完成大修，這套AIoT平臺已經導入二號高爐場域中。中鋼也正在規劃，要將AIoT平臺導入其他座高爐中。許雍達表示，更長久的計畫，則是要開發煉焦、燒結兩大原料加工廠的智能模組，並且整合到AIoT平臺來監控運用，「這樣一來，我們在高爐的現場就能看到原料加工廠的生產數據，如果有異況，高爐也能同步調整、配合。」

高爐AI應用大剖析

「高爐出了問題，就得降風停產，如果能見微知著，在發生狀況前預先防範，就能降低損失產量的風險。」中鋼技術部門代理副總經理鄭際昭，一句話點出高爐AI的重要性。

用AI煉鐵，導入27項高爐場域智慧應用，被中鋼視為第一個進化里程。27項應用中，中鋼不只開發高爐爐況分析監控，也開發周邊設備的AI應用，比如原料輸送帶的預測維修、熱風爐生產效率與耗能監控、現場人員的安全監控等。

其中，高爐本身的爐況監測，更是AI開發的重點任務，因為高爐就像是一個黑盒子，為了掌控高爐的生產狀況，中鋼得在高爐上裝設多種感測器，以AI監控生產數據，才能提前發現問題，並及早因應。

因此，在眾多應用中，中鋼特別介紹7項與高爐爐況分析相關的智慧應用，揭密1,500度高熱密閉的生產環境，如何靠AI監控。

1 爐內布料情形監控

技術關鍵 靠掃描感測儀器與熱像儀，偵測原料、粉塵、高溫氣體分佈狀況，並將資料視覺化

效用 監控氣流是否穩定、布料形狀是否符合預期

將原料從爐頂添加到高爐時，過去無法得知實際布料狀況，但現在，中鋼在爐頂布建掃描感測儀器，就能即時偵測原料在高爐內的分佈，同時透過爐內的熱像儀，掃描粉塵、高溫氣體的分佈，就能比對得知目前氣流是否穩定，布料形狀是否符合預期。中鋼也將量測到的數據，以視覺化的方式來呈現。

2 管道流預警AI

技術關鍵 透過AI判斷爐內壓力與溫度分布是否超過異常值，來預測管道流異常

效用 提早預測管道流異常發生可能性，調整生產參數來因應

一般來說，高爐運作的理想情況，是從下面鼓風，爐氣均勻往上傳遞，將原料還原熔融。但是，若爐氣無法穩定通過爐料，而是累積在某個區塊，就可能因為壓力蓄積過大往上竄出，造成爐頂洩壓閥排放，或造成設備損傷。「氣集中在一個地方，壓力大到一個程度就會往上衝，就好像人打嗝，不能等到衝上來，要想辦法及時拯救。」鄭際昭形容。

為了提早發現管道流的情形，中鋼在高爐爐殼上設置壓力量測與溫度量測點，分別將溫度與壓力的分佈視覺化呈現，若結合兩者數值，發現壓力差超過異常值，或是局部溫度過高，AI判斷為管道流異常可能發生，「系統會發出預警，引導操作人員先降低風壓、風量，」中鋼煉鐵廠高爐二課課長許雍達表示，越早預測出管道流異常，就能越早調整生產參數，來避免管道流發生。

3 爐壁厚度監測AI

技術關鍵 透過爐壁探鑽深度與周圍壁面溫度變化的關聯性，訓練AI靠爐壁溫度變化，判斷爐壁厚薄

效用 預測爐壁冷卻元件受損情形，安排檢修時程

高爐爐壁冷卻元件（冷卻壁）若被蝕破，就可能造成嚴重的生產危機。然而，單從高爐外觀，無法得知爐壁冷卻元件被侵蝕的程度，中鋼以往只能定期量測來推斷爐壁狀況，定期檢修，來降低意外風險。

要監測爐壁厚薄，中鋼在爐壁裝設測溫感測器，找出溫度與爐壁厚薄的關聯性。鄭際昭解釋，一般來說，爐壁變薄後，測得的爐壁溫度會升高，雖然鐵水在壁面結塊或脫落，也會造成可能造成溫度改變，但相較於正常爐壁狀況，溫度變化頻率會較為劇烈。

因此，中鋼以探鑽點位附近的歷史溫度變化，結合實際探鑽的厚度訓練AI模型，再套用到高爐其他測溫點位上，來推測爐壁不同位置的侵蝕狀況。

4 爐壁結塊預測AI

技術關鍵 透過爐壁溫度變化頻率預測結塊情形

效用 監測到爐壁溫度變化異常，提早因應避免結塊情形惡化

高爐溫度一旦降低，就可能造成鐵水冷卻結塊、附著在爐壁上，若爐壁的結塊大量滑落，導致爐氣異常溢出，就可能發生操作上的危險，「許多高爐曾經因為高爐內部結塊過大，掉落時打到鼓風嘴，導致鼓風元件受損漏氣。」許雍達說。

為了維持爐況穩定與操作安全，中鋼開發了爐壁結塊預測AI，當發現溫度變化波動越來越小，就能推測爐壁內部結塊，並提前調整高爐的生產條件，避免結塊情形更嚴重。

許雍達表示，這套AI應用目前部署在三、四號高爐，因為這兩座高爐的爐內冷卻元件形式與一、二號高爐不同，更容易發生產生爐壁結塊問題，較有應用AI的急迫性。

5 爐熱溫度預測AI

技術關鍵 量測出鐵口的鐵水溫度變化，參考操作條件、鐵渣的化性分析，學習預測未來爐熱

效用 預測未來2～4小時內的爐熱變化，提前調整生產參數來因應

對於正在生產鐵水的高爐來說，必須維持一定的爐熱，高爐才能穩地熔煉鐵水，若溫度異常大幅下降，就可能造成爐冷危機，需花費許多時間調整加熱，一旦惡化至鐵水凝固無法排出，復原工作會很困難。

「發生一次就是上億的損失，所以我們要盡可能避免走到這一步。」鄭際昭點出爐熱預測的重要性。

中鋼在建立爐熱溫度預測AI時，就是透過量測出鐵口的鐵水溫度變化，參考操作條件、鐵渣的化性分析，學習預知未來2～4小時的爐熱趨勢，藉此訓練出爐熱預測的AI，若預測到未來爐熱可能下降，就能即時調整生產參數，微調風溫、噴煤量，來維持爐熱的穩定。

6 鼓風嘴噴煤預警AI

技術關鍵 透過大量鼓風嘴噴煤影像訓練AI判斷異常

效用 自動化找出噴煤槍過短、噴煤口堵塞等異常影像，減少人力監控負擔

中鋼透過在鼓風嘴噴吹粉煤，來減少原料焦炭的使用，同時，也能透過粉煤噴吹量來調節爐熱。不過，粉煤噴吹的狀況，過去需要人工監控，透過攝影機將風口影像傳輸到中控室，來監測是否發生噴嘴阻塞、或是噴煤槍設備耗損的情形，而且，需監控的影像還不只一個，光是二號高爐就有30個風口影像需要監控。

為了減少人力的負擔，中鋼正在運用歷史監測影像，訓練影像辨識AI，來自動監診噴煤槍設備，找出噴煤槍過短、噴煤口堵塞等異狀。

7 高爐原料粒徑分析AI

技術關鍵 透過原料粒徑影像資料，訓練AI進行粒徑分析

效用 即時辨識原料粒徑大小與分布，調整入料情形來降低燃料率

將原料送入高爐時，若原料的粒徑大小符合預期、分布較平均，有助於爐況穩定、降低燃料率。中鋼甚至推算，高爐燃燒料率每減少1%，每年可以減少上億的燃料經費，因此，中鋼用AI來即時辨識原料的粒徑大小，即時計算進入到高爐原料粒徑分布，以及是否混雜到其他原料等情況，再根據分析結果來調整原料分布，有助於穩定爐況、降低燃料率。

附圖：光是二號高爐，中鋼就投資約5,700萬元來建置智慧應用，投資的金額雖大，但帶來的效益更可觀，預估每年可以降低成本3,270萬元，減少排放溫室氣體2,217噸。（攝影／洪政偉）

資料來源：https://www.ithome.com.tw/news/142938

📜 [專欄新文章] [ZKP 讀書會] Trust Token Browser API
✍️ Yuren Ju
📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

Trust Token API 是一個正在標準化的瀏覽器 API，主要的目的是在保護隱私的前提下提供跨站授權 (Cross-domain authorization) 的功能，以前如果需要跨站追蹤或授權通常都使用有隱私疑慮的 Cookies 機制，而 Trust Token 則是希望在保護隱私的前提下完成相同的功能。

會在 ZKP (Zero-knowledge proof) 讀書會研究 Trust Token 主要是這個 API 採用了零知識證明來保護隱私，這也是這次讀書會中少見跟區塊鏈無關的零知識證明應用。

問題

大家應該都有點了一個產品的網頁後，很快的就在 Facebook 或是 Google 上面看到相關的廣告。但是產品網頁並不是在 Facebook 上面，他怎麼會知道我看了這個產品的頁面？

通常這都是透過 Cookie 來做跨網站追蹤來記錄你在網路上的瀏覽行為。以 Facebook 為例。

當使用者登入 Facebook 之後，Facebook 會透過 Cookie 放一段識別碼在瀏覽器裡面，當使用者造訪了有安裝 Facebook SDK 來提供「讚」功能的網頁時，瀏覽器在載入 SDK 時會再度夾帶這個識別碼，此時 Facebook 就會知道你造訪了特定的網頁並且記錄下來了。如此一來再搭配其他不同管道的追蹤方式，Facebook 就可以建構出特定使用者在網路上瀏覽的軌跡，從你的瀏覽紀錄推敲喜好，餵給你 Facebook 最想給你看的廣告了。

不過跨站追蹤也不是只能用在廣告這樣的應用上，像是 CDN (Content Delivery Network) 也是一個應用場景。CDN 服務 Cloudflare 提供服務的同時會利用 Captcha 先來確定進入網站的是不是真人或是機器人。而他希望使用者如果是真人時下次造訪同時也是採用 Cloudflare 服務的網站不要再跳出 Captcha 驗證訊息。

雖然 Cloudflare 也需要跨站驗證的功能來完成他們的服務，但是相較於 Google 或 Facebook 來說他們是比較沒那麼想知道使用者的隱私。有沒有什麼辦法可以保護使用者隱私的狀況下還能完成跨站驗證呢？

這就是今天要講的新 API: Trust Token。

Trust Token API - The Chromium Projects

Trust Token / Privacy Pass 簡介

Trust Token 其實是由 Privacy Pass 延伸而來。Privacy Pass 就是由 Cloudflare 所開發的實驗性瀏覽器延伸套件實作一個驗證機制，可以在不透漏過多使用者隱私的前提下實作跨站驗證。而 Trust Token 則是標準化的 Privacy Pass，所以兩個運作機制類似，但是實作方式稍有不同。

先看一下 Privacy Pass 是如何使用。因為這是實驗性的瀏覽器延伸套件所以看起來有點陽春，不過大致上還是可以了解整個概念。

以 hCaptcha 跟 Cloudflare 的應用為例，使用者第一次進到由 Cloudflare 提供服務的網站時，網站會跳出一些人類才可以解答的問題比如說「挑出以下是汽車的圖片」。

當使用者答對問題後，Cloudflare 會回傳若干組 blind token，這些 blind token 還會需要經過 unblind 後才會變成真正可以使用的 token，這個過程為 issue token。如上圖所示假設使用者這次驗證拿到了 30 個 token，在每次造訪由 Cloudflare 服務的網站時就會用掉一個 token，這個步驟稱為 redeem token。

但這個機制最重要的地方在於 Cloudflare 並無法把 issue token 跟 redeem token 這兩個階段的使用者連結在一起，也就是說如果 Alice, Bob 跟 Chris 都曾經通過 Captcha 測試並且獲得了 Token，但是在後續瀏覽不同網站時把 token 兌換掉時，Clouldflare 並無法區分哪個 token 是來自 Bob，哪個 token 是來自 Alice，但是只要持有這種 token 就代表持有者已經通過了 Captcha 的挑戰證明為真人。

但這樣的機制要怎麼完成呢？以下我們會透過多個步驟的例子來解釋如何達成這個目的。不過在那之前我們要先講一下 Privacy Pass 所用到的零知識證明。

零知識證明 (Zero-knowledge proof)

零知識證明是一種方法在不揭露某個祕密的狀態下，證明他自己知道那個秘密。

Rahil Arora 在 stackexchange 上寫的比喻我覺得是相對好理解的，下面簡單的翻譯一下：

假設 Alice 有超能力可以幾秒內算出樹木上面有幾片樹葉，如何在不告訴 Bob 超能力是怎麼運作並且也不告訴 Bob 有多少片葉子的狀況下證明 Alice 有超能力？我們可以設計一個流程來證明這件事情。

Alice 先把眼睛閉起來，請 Bob 選擇拿掉樹上的一片葉子或不拿掉。當 Alice 睜開眼睛的時候，告訴 Bob 他有沒有拿掉葉子。如果一次正確的話確實有可能是 Alice 幸運猜到，但是如果這個過程連續很多次時 Alice 真的擁有數葉子的超能力的機率就愈來愈高。

而零知識證明的原理大致上就是這樣，你可以用一個流程來證明你知道某個秘密，即使你不真的揭露這個秘密到底是什麼，以上面的例子來說，這個秘密就是超能力運作的方式。

以上就是零知識證明的概念，不過要完成零知識證明有很多各式各樣的方式，今天我們要介紹的是 Trust Token 所使用的零知識證明：DLEQ。

DLEQ (Discrete Logarithm Equivalence Proof)

說明一下以下如果小寫的變數如 c, s 都是純量 (Scalar)，如果是大寫如 G, H則是橢圓曲線上面的點 (Point)，如果是 vG 則一樣是點，計算方式則是 G 連續相加 v 次，這跟一般的乘法不同，有興趣可以程式前沿的《橢圓曲線加密演算法》一文解釋得比較詳細。

DLEQ 有一個前提，在系統中的所有人都知道公開的 G 跟 H 兩個點，此時以下等式會成立：

假設 Peggy 擁有一個秘密 s 要向 Victor 證明他知道 s 為何，並且在這個過程中不揭露 s 真正的數值，此時 Victor 可以產生一個隨機數 c 傳送給 Peggy，而 Peggy 則會再產生一個隨機數 v 並且產生 r，並且附上 vG, vH, sG, sH：

r = v - cs

所以 Victor 會得到 r, sG, sH, vG, vH 再加上他已經知道的 G, H。這個時候如果 Victor 計算出以下兩個等式就代表 Peggy 知道 s 的真正數值：

vG = rG + c(sG)vH = rH + c(sH)

我們舉第二個等式作為例子化簡：

vH = rH + c(sH) // 把 r 展開成 v - csvH = (v - cs)H + c(sH) // (v - cs)H 展開成 vH - csHvH = vH - c(sH) + c(sH) // 正負 c(sH) 消掉vH = vH

這樣只有 Peggy 知道 s 的狀況下才能給出 r，所以這樣就可以證明 Peggy 確實知道 s。

從簡易到實際的情境

Privacy Pass 網站上透過了循序漸進的七種情境從最簡單的假設到最後面實際使用的情境來講解整個機制是怎麼運作的。本文也用相同的方式來解釋各種情境，不過前面的例子就會相對比較天真一點，就請大家一步步的往下看。

基本上整個過程是透過一種叫做 Blind Signature 的方式搭配上零知識證明完成的，以下參與的角色分為 Client 與 Server，並且都會有兩個階段 issue 與 redeem token。

Scenario 1

如果我們要設計一個這樣可以兌換 token 來確認身分的系統，其中有一個方法是透過橢圓曲線 (elliptic curve) 完成。Client 挑選一個在橢圓曲線上的點 T 並且傳送給 Server，Server 收到後透過一個只有 Server 知道的純量 (scalar) s 對 T 運算後得到 sT 並且回傳給 Client，這個產生 sT 的過程稱為 Sign Point，不過實際上運作的原理就是橢圓曲線上的連續加法運算。

SignPoint(T, s) => sT

等到 Client 需要兌換時只要把 T 跟 sT 給 Server，Server 可以收到 T 的時候再 Sign Point 一次看看是不是 sT 就知道是否曾經 issue 過這個 token。

Issue

以下的範例，左邊都是 Client, 右邊都是 Server。 -> 代表 Client 發送給 Server，反之亦然。

// Client 發送 T 給 Server, 然後得到 sT

T -> <- sT

Redeem

// Client 要 redeem token 時，傳出 T 與 sT

T, sT ->

問題：Linkability

因為 Server 在 issue 的時候已經知道了 T，所以基本上 Server 可以透過這項資訊可以把 issue 階段跟 redeem 階段的人連結起來進而知道 Client 的行為。

Scenario 2

要解決上面的問題，其中一個方法是透過 Blind Signature 達成。Client 不送出 T，而是先透過 BlindPoint 的方式產生 bT 跟 b，接下來再送給 Server bT。Server 收到 bT 之後，同樣的透過 Sign Point 的方式產生結果，不一樣的地方是情境 1 是用 T，而這邊則用 bT 來作 Sign Point，所以得出來的結果是 s(bT)。

Client:BlindPoint(T) => (bT, b)

Server:SignPoint(bT, s) => sbT

而 Blind Signature 跟 Sign Point 具備了交換律的特性，所以得到 s(bT) 後可以透過原本 Client 已知的 b 進行 Unblind：

UnblindPoint(sbT, b) => sT

這樣一來在 Redeem 的時候就可以送出 T, sT 給 Server 了，而且透過 SignPoint(T, s) 得出結果 sT’ 如果符合 Client 傳來的 sT 就代表確實 Server 曾經簽過這個被 blind 的點，同時因為 T 從來都沒有送到 Server 過，所以 Server 也無法將 issue 與 redeem 階段的 Client 連結在一起。

Issue

bT -> <- s(bT)

Redeem

T, sT ->

問題：Malleability

以上的流程其實也有另外一個大問題，因為有交換律的關係，當 Client 透過一個任意值 a 放入 BlindPoint 時產生的 a(sT) 就會等於 s(aT)：

BlindPoint(sT) => a(sT), a// a(sT) === s(aT)

此時如果將 aT 跟 s(aT) 送給 Server Redeem，此時因為

SignPoint(aT, s) => s(aT)

所以就可以兌換了，這樣造成 Client 可以無限地用任意數值兌換 token。

Scenario 3

這次我們讓 Client 先選擇一個純數 t，並且透過一種單向的 hash 方式來產生一個在橢圓曲線上的點 T，並且在 redeem 階段時原本是送出 T, sT 改成送出 t, sT。

因為 redeem 要送出的是 t，上個情境時透過任意數 a 來產生 s(aT) 的方法就沒辦法用了，因為 t 跟 sT 兩個參數之間並不是單純的再透過一次 BlindPoint() 就可以得到，所以就沒辦法無限兌換了。

Issue

T = Hash(t) bT -> <- sbT

Redeem

t, sT ->

問題：Redemption hijacking

在這個例子裏面，Client 其實是沒有必要傳送 sT 的，因為 Server 僅需要 t 就可以計算出 sT，額外傳送 sT 可能會導致潛在的 Redemption hijacking 問題，如果在不安全的通道上傳輸 t, sT 就有可能這個 redemption 被劫持作為其他的用途。

不過在網站上沒講出實際上要怎麼利用這個問題，但是少傳一個可以計算出來的資料總是好的。Client 只要證明他知道 sT 就好，而這可以透過 HMAC (Hash-based Message Authentication Code) 達成。

Scenario 4

步驟跟前面都一樣，唯一不一樣的地方是 redeem 的時候原本是傳 t, sT，現在則改傳 t, M, HMAC(sT, M)，如果再介紹 HMAC 篇幅會太大，這邊就不解釋了，但可以是作是一個標準的 salt 方式讓 Hash 出來的結果不容易受到暴力破解。

這樣的特性在這個情境用很適合，因為 Server 透過 t 就可以計算出 sT，透過公開傳遞的 M 可以輕易地驗證 client 端是否持有 sT。

Issue

T = Hash(t) bT -> <- sbT

Redeem

t, M, HMAC(sT, M) ->

問題：Tagging

這邊的問題在於 Server 可以在 issue 階段的時候用不一樣的 s1, s2, s3 等來發出不一樣的 sT’，這樣 Server 在 Redeem 階段就可以得知 client 是哪一個 s。所以 Server 需要證明自己每次都用同樣的 s 同時又不透漏 s 這個純亮。

要解決這個問題就需要用到前面我們講解的零知識證明 DLEQ 了。

Scenario 5

前面的 DLEQ 講解有提到，如果有 Peggy 有一個 s 秘密純量，我們可以透過 DLEQ 來證明 Peggy 知道 s，但是又不透漏 s 真正的數值，而在 Privacy Pass 的機制裡面，Server 需要證明自己每次都用 s，但是卻又不用揭露真正的數值。

在 Issue 階段 Client 做的事情還是一樣傳 bT 給 Server 端，但 Server 端的回應就不一樣了，這次 Server 會回傳 sbT 與一個 DLEQ 證明，證明自己正在用同一個 s。

首先根據 DLEQ 的假設，Server 會需要先公開一組 G, H 給所有的 Client。而在 Privacy Pass 的實作中則是公開了 G 給所有 Client，而 H 則改用 bT 代替。

回傳的時候 Server 要證明自己仍然使用同一個 s 發出 token，所以附上了一個 DLEQ 的證明 r = v - cs，Client 只要算出以下算式相等就可證明 Server 仍然用同一個 s (記住了 H 已經改用 bT 代替，此時 client 也有 sbT 也就是 sH)：

vH = rH + c(sH) // H 換成 bTvbT = rbT + c(sbT) // 把 r 展開成 v - csvbT = (v - cs)bT + c(sbT) // (v - cs)bT 展開成 vbT - csbTvbT = vbT - c(sbT) + c(sbT) // 正負 c(sbT) 消掉vbT = vbT

這樣就可以證明 Server 依然用同一個 s。

Issue

T = Hash(t) bT -> <- sbT, DLEQ(bT:sbT == G:sG)

Redeem

t, M, HMAC(sT, M) ->

問題：only one redemption per issuance

到這邊基本上 Privacy Pass 的原理已經解釋得差不多了，不過這邊有個問題是一次只發一個 token 太少，應該要一次可以發多個 token。這邊我要跳過源文中提到的 Scenario 6 解釋最後的結果。

Scenario 7

由於一次僅產生一個 redeem token 太沒效率了，如果同時發很多次，每次都產生一個 proof 也不是非常有效率，而 DLEQ 有一個延伸的用法 “batch” 可以一次產生多個 token, 並且只有使用一個 Proof 就可以驗證所有 token 是否合法，這樣就可以大大的降低頻寬需求。

不過這邊我們就不贅述 Batch DLEQ 的原理了，文末我會提及一些比較有用的連結跟確切的源碼片段讓有興趣的人可以更快速的追蹤到源碼片段。

Issue

T1 = Hash(t1) T2 = Hash(t2)T3 = Hash(t3)b1T1 ->b2T2 ->b3T3 -> c1,c2,c3 = H(G,sG,b1T1,b2T2,b3T3,s(b1T1),s(b2T2),s(b3T3)) <- sb1T1 <- sb2T2 <- sb3T3 <- DLEQ(c1b1T1+c2b2T2+c3b3T3:s(c1b1T1+c2b2T2+c3b3T3) == G: sG)

Redeem

t1, M, HMAC(sT1, M) ->

結論

Privacy Token / Trust Token API 透過零知識證明的方式來建立了一個不需要透漏太多隱私也可以達成跟 cookie 相同效果的驗證方式，期待可以改變目前許多廣告巨頭透過 cookie 過分的追蹤使用者隱私的作法。

不過我在 Trust Token API Explainer 裡面看到這個協議裡面的延伸作法還可以夾帶 Metadata 進去，而協議制定的過程中其實廣告龍頭 Google 也參與其中，希望這份協議還是可以保持中立，盡可能地讓最後版本可以有效的在保護隱私的情況下完成 Cross-domain authorization 的功能。

參考資料

IETF Privacy Pass docs

Privacy Pass: The Protocol

Privacy Pass: Architectural Framework

Privacy Pass: HTTP API

Cloudflare

Supporting the latest version of the Privacy Pass Protocol (cloudflare.com)

Chinese: Cloudflare支持最新的Privacy Pass扩展_推动协议标准化

Other

Privacy Pass official website

Getting started with Trust Tokens (web.dev)

WICG Trust Token API Explainer

Non-interactive zero-knowledge (NIZK) proofs for the equality (EQ) of discrete logarithms (DL) (asecuritysite.com) 這個網站非常實用，列了很多零知識證明的源碼參考，但可惜的是 DLEQ 這個演算法講解有錯，讓我在理解演算法的時候撞牆很久。所以使用的時候請多加小心，源碼應該是可以參考的，解釋的話需要斟酌一下。

關鍵源碼

這邊我貼幾段覺得很有用的源碼。

privacy pass 提供的伺服器端產生 Proof 的源碼

privacy pass 提供的瀏覽器端產生 BlindPoint 的源碼

github dedis/kyber 產生 Proof 的源碼

[ZKP 讀書會] Trust Token Browser API was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

👏 歡迎轉載分享鼓掌

【全球氣象產業的發展前景 50 原來是"低優先"】

過去十多年，我們均透過既有正規的管道，提出反映，是否氣象資料能夠考量民間產業需求，能夠和其他國家一樣有同樣標準的發展環境，我們也願意付費，但不要那麼貴，或是能夠提供和各國類似的條件。但始終沒有具體的進步。
這次我主動希望政府能夠考量規費法在各部會的問題，也是拋磚引玉，好多朋友和我說很多民間很多能量因為規費法，無法發展，唯一的來源變成標該單位的標案，這的確很可惜。
不過我們申請後，回應卻是讓大家很無奈也憤怒，原來我們十多年來的反應，是被當成『低優先』! 為何很多國家都反而是把幫助氣象產業發展當成是主力，我們卻是低優先~? 凸顯台灣根本不重視民間產業的發展，有點情何以堪!
--------------------------------------------------------------
回復類型：已開放或依申請提供
聯絡人：林先生
聯絡人電話：(02) 2349-XXXX
聯絡人信箱：XXXX@cwb.gov.tw
依申請提供連結1：https://e-service.cwb.gov.tw/wdps/
Comment:
您好, 一、交通部中央氣象局（以下簡稱氣象局）開放氣象資料供應管道說明如下： （一）氣象局資料開放平台（含政府資料開放平台）提供氣象資料下載 此管道不收取任何費用，除提供網站人機介面（UI）供使用者取用資料外，亦提供機器對機器的介面（API）供程式自動化的取用資料。但是，因為氣象局資源有限，目前尚無法將所有開放資料皆經由此平台提供，但會依社會的需求及以下之優先次序，逐步向氣象資料完全開放之目標邁進：
1、 高優先：一般性觀測資料、預報資料及預警資料，此類資料使用族群最廣，使用者最多，其應用範圍包括民生、災防、遊憩、傳播、產銷、物流等，目前已完全於資料開放平台提供。
2、 中優先：歷史觀測資料，依資料項目數位化及品質管理與檢核進程逐步開放，其應用需要在背景氣候的建立及學研應用。以歷史觀測資料之開放為例，目前已開放至2005年之所有氣象觀測資料。
3、 低優先：高專業度及複雜度的特定領域研究或加值應用的近即時觀測、預報資料（例如：使用者少，需具有一定程度的專業能力方能適當詮釋資料的意義與應用。）
（二）特定用途的氣象相關資料網站 提供特定應用領域、較專業包含圖形、觀測或預報（警）等資料，此類網站例如颱風資料庫、數值天氣預報、地球物理資料管理系統、歷史觀測資料查詢下載、劇烈天氣監測等。此管道提供網站介面（UI）供使用者取用資料，亦不收取費用。
（三）客製化或加值型資料服務 資料需要氣象局認證、或有特定資料格式需求、或需提供額外的資料傳輸服務、或氣象局資料開放平台無法滿足之資料供應服務，需要氣象局投入額外的人力、物力及時間加以處理或維持24小時穩定維運者，則可依「交通部中央氣象局規費收費標準」，向氣象局申購所需的氣象資料，氣象局再依雙方可接受之管道或透過氣象局的專業資料供應服務平台（PDS, Professional Data Services）提供所需氣象資料。
二、關於現行規費收費標準檢討 依據財政部國庫署訂定之規費法，應考量成本變動趨勢、消費者物價指數變動情形及資訊環境變動等因素影響，定期檢討規費收費標準，氣象局係依此規定至少每3年檢討1次「交通部中央氣象局規費收費標準」，目前已在進行新一階段的檢討研議。因修訂規費收費標準程序嚴謹，且需考量各方因素，氣象局預計於民國111年前依內外環境與成本狀況，完成新一階段收費標準的再檢討與修訂。
三、交通部中央氣象局資料開放概況如下：
（一）氣象局自民國86年起即建置網站公開提供各項氣象測報資訊，自103年起並配合政府資料開放政策，建置開放資料平台，依據不同資料特性，提供機器可讀之資料。氣象局開放資料平台為回應各界對氣象開放資料運用更為便利之期待，擬定氣象開放資料共通格式規範，供民眾與系統開發業者透過UI和API取用所需資料進行加值運用，現已提供479資料項，且持續增加資料開放項目，目前每月平均有9,900萬次民眾下載，且持續增加資料開放項目。以108年12月統計之OPEN DATA較頻繁下載使用的資料項與下載量為例，前3名下載資料項分別為一般天氣預報-今明36小時天氣預報（下載次數38,739,604、下載人數728、下載流量597 GB）、自動雨量站-雨量觀測資料（下載次數15,019,296、下載人數271、下載流量3825 GB）、自動氣象站-氣象觀測資料（下載次數7,558,830、下載人數584、下載流量5016 GB）。
（二）有關所提開放資料的時間落差與品項及解析度等，說明如下： 以觀測資料為例：開放資料平台所提供的觀測資料，已整合不同來源、不同種類之氣象觀測，並於收集資料後進行一定的資料品質檢核程序，期能提升所提供資料的品質。然也因不同種類的資料處理過程需時不同，以致在網頁呈現或是OPEN DATA資料提供上略有時間差異，但不致於有明顯的差異。以複雜度較高的雷達觀測整合回波資料為例，自雷達原始資料接收後經除錯、運算、整合至資料產出轉換至官網顯示平均約需9分鐘，而OPEN DATA平台的影像圖及數值資料提供則平均約為7至8分鐘，其時間差異均為資料處理與傳遞所必需之時間，並未有太大的延遲情形；在區域數值天氣預報模式輸出資料方面，氣象局已提供現行作業使用之最高解度3公里、地面以及標準層共12層、預報時間至84小時的預報資料，包含氣壓(高度場)、氣溫、相對溼度、風速、風向、降雨等主要氣象參數的數值資料，其內容以可供天氣預報詮釋與加值應用，未來亦將配合模式作業延伸，提供至120小時的預報資料。惟由於數值模式完整輸出及雷達觀測的原始資料量龐大，以每天4次120小時的數值天氣預報區域模式產品資料量約為1720GB，至少需要768Mb/s的頻寬才能勉強進行即時傳輸作業，另，氣象局所屬雷達站在有劇烈天氣的狀況下，每日資料量約需72GB，至少需要32Mb/s的頻寬才能勉強進行即時傳輸作業，即時傳輸需占用大量的頻寬。而此種資料的需求者多屬相當專業之少數使用者，為使資源能更有效地應用，在無償開放平台的資料提供上，屬低優先度的情境，因此後續更多層場資料之提供，需視使用者需求的急迫性與作業資源的可容納性，滾動進行調整。
（三）交通部中央氣象局規費收費標準所有項目（不含出版品）共59大項，已開放共達43大項以上，其他尚未開放項目，主要為高解析度原始觀測或預報模式數位資料，如雷達、衛星、地震及數值模式資料，另有些雖尚未全項開放之產品實已依實務需求部分開放，因此就內容而言已開放細項實超過43項。若以前述之前3名下載資料換算為規費收入，每月至少達數百萬元，然為促進政府資料的蓬勃應用，配合政府積極推動的資料開放政策是氣象局相當重要的施政方向。
（四）經查美國、日本與澳洲之即時雷達資料供應狀況，日本及澳洲根據不同的資料需求，均收取使用費，氣象局之整合雷達回波圖資及其數據資料則放置於開放平台，實際上未收取費用。
（五）未來，氣象局仍將持續精進資料處理技術，並依據大多數民眾使用氣象資料的需求及優先度，投入適當的資源持續進行氣象測報資料開放的工作。 交通部(中央氣象局) 敬復
結案狀態：已結案(有開放)

【全球氣象產業的發展前景 總整理】
https://www.facebook.com/170435726987/posts/10158593491761988/?d=n
#globalweatherenterprise
#台灣真的可以發展氣象產業
#交通部氣象局局長說台灣沒有氣象產業
#會以連載方式讓大家了解全球氣象產業
彭啟明

Python程式入門與Django架站第2次範例BMI增加對應的圖片與CSS與樣板與表單

上課內容：
01_重點回顧與範例hello1到hello4
02_將年齡範例改為Django網頁互動版本之一
03_將年齡範例改為Django網頁互動版本之二
04_用GET傳遞兩個以上的參數
05_練習題BMI練習改為DJANGO版本說明
06_練習題BMI練習改為DJANGO版本實作
07_BMI增加對應的圖片之一
08_BMI增加對應的圖片之二
09_BMI增加CSS與樣板之一
10_BMI增加CSS與樣板之二
11_增加表單計算結果
12_增加BMI表單結果說明
13_預告下周其他練習題

完整教學
http://goo.gl/aQTMFS

吳老師教學論壇
http://www.tqc.idv.tw/

教學論壇(之後課程會放論壇上課學員請自行加入)：
https://groups.google.com/forum/#!forum/ncu_python_2019

懶人包：
EXCEL函數與VBA http://terry28853669.pixnet.net/blog/category/list/1384521
EXCEL VBA自動化教學 http://terry28853669.pixnet.net/blog/category/list/1384524

建置Python與Django開發環境
基本語法與結構控制
迴圈、資料結構及函式
建立專案及app與檔案處理
視圖與模版
資料庫及後台管理
資料查詢與新增功能實作
資料刪除和修改功能實作
專題：新聞公告系統、網站留言版、網路相簿、購物車、美食地圖
部署網站

參考書目
Python架站特訓班：Django最強實戰作者： 鄧文淵/總監製, 文淵閣工作室/編著?出版社：

碁峰?出版日期：2017/08/31

吳老師 108/5/10

Python,Django,中央大學資工系,福建師範大學,程式設計,線上教學,PYTHON安裝環境,網路爬蟲

Python程式入門與Django架站第2次範例BMI增加對應的圖片與CSS與樣板與表單

上課內容：
01_重點回顧與範例hello1到hello4
02_將年齡範例改為Django網頁互動版本之一
03_將年齡範例改為Django網頁互動版本之二
04_用GET傳遞兩個以上的參數
05_練習題BMI練習改為DJANGO版本說明
06_練習題BMI練習改為DJANGO版本實作
07_BMI增加對應的圖片之一
08_BMI增加對應的圖片之二
09_BMI增加CSS與樣板之一
10_BMI增加CSS與樣板之二
11_增加表單計算結果
12_增加BMI表單結果說明
13_預告下周其他練習題

完整教學
http://goo.gl/aQTMFS

吳老師教學論壇
http://www.tqc.idv.tw/

教學論壇(之後課程會放論壇上課學員請自行加入)：
https://groups.google.com/forum/#!forum/ncu_python_2019

懶人包：
EXCEL函數與VBA http://terry28853669.pixnet.net/blog/category/list/1384521
EXCEL VBA自動化教學 http://terry28853669.pixnet.net/blog/category/list/1384524

建置Python與Django開發環境
基本語法與結構控制
迴圈、資料結構及函式
建立專案及app與檔案處理
視圖與模版
資料庫及後台管理
資料查詢與新增功能實作
資料刪除和修改功能實作
專題：新聞公告系統、網站留言版、網路相簿、購物車、美食地圖
部署網站

參考書目
Python架站特訓班：Django最強實戰作者： 鄧文淵/總監製, 文淵閣工作室/編著?出版社：

碁峰?出版日期：2017/08/31

吳老師 108/5/10

Python,Django,中央大學資工系,福建師範大學,程式設計,線上教學,PYTHON安裝環境,網路爬蟲

Python程式入門與Django架站第2次範例BMI增加對應的圖片與CSS與樣板與表單

上課內容：
01_重點回顧與範例hello1到hello4
02_將年齡範例改為Django網頁互動版本之一
03_將年齡範例改為Django網頁互動版本之二
04_用GET傳遞兩個以上的參數
05_練習題BMI練習改為DJANGO版本說明
06_練習題BMI練習改為DJANGO版本實作
07_BMI增加對應的圖片之一
08_BMI增加對應的圖片之二
09_BMI增加CSS與樣板之一
10_BMI增加CSS與樣板之二
11_增加表單計算結果
12_增加BMI表單結果說明
13_預告下周其他練習題

完整教學
http://goo.gl/aQTMFS

吳老師教學論壇
http://www.tqc.idv.tw/

教學論壇(之後課程會放論壇上課學員請自行加入)：
https://groups.google.com/forum/#!forum/ncu_python_2019

懶人包：
EXCEL函數與VBA http://terry28853669.pixnet.net/blog/category/list/1384521
EXCEL VBA自動化教學 http://terry28853669.pixnet.net/blog/category/list/1384524

建置Python與Django開發環境
基本語法與結構控制
迴圈、資料結構及函式
建立專案及app與檔案處理
視圖與模版
資料庫及後台管理
資料查詢與新增功能實作
資料刪除和修改功能實作
專題：新聞公告系統、網站留言版、網路相簿、購物車、美食地圖
部署網站

參考書目
Python架站特訓班：Django最強實戰作者： 鄧文淵/總監製, 文淵閣工作室/編著?出版社：

碁峰?出版日期：2017/08/31

吳老師 108/5/10

Python,Django,中央大學資工系,福建師範大學,程式設計,線上教學,PYTHON安裝環境,網路爬蟲