關於 snapshot linux ，我們在網路上蒐集到這些相關的討論、資訊與評價

利用晶片級安全保護工業物聯網終端

作者 : Nitin Dahad，EE Times歐洲特派記者

• 2021-01-25

我們必須重視物聯網終端裝置的安全性，因為它們是防禦網路攻擊的重要一環。無論是雲端伺服器還是邊緣感測器，最終都要節點上的終端得到了保護，才能保護整個系統——至少可以降低遭受攻擊的可能。

談到物聯網(IoT)安全時，大多數人都會提到兩件事：一是建立信任根(RoT)作為安全基礎，二是不要只關注終端裝置，而是要考慮整個生態系統和產品生命週期的安全性。

然而，我們必須重視終端裝置的安全性，因為它們是防禦網路攻擊的重要一環。無論是雲端伺服器還是邊緣感測器，最終都要節點上的終端得到了保護，才能保護整個系統——至少可以降低遭受攻擊的可能。

因此，本文特意側重於設備安全性，並同時認知必須更全面地考慮安全性：作為整個工廠或環境更廣泛的安全性框架，其中，可連網裝置在提高生產率和效率中發揮重要作用。

如工業網際網路網聯盟(Industrial Internet Consortium，IIC)的安全架構所示，終端保護有助於邊緣和雲端設備實現防禦功能(圖1)。終端可以是工業物聯網(IIoT)系統中的任何一個元素，同時具有運算和通訊功能，其自身功能可能會暴露給防火牆外的任何人。這些終端可以是邊緣裝置、通訊基礎結構、雲端伺服器或其間的任何裝置，每個終端都有不同的硬體局限，決定了可獲得的保護等級。

終端保護是透過終端中的權威身份辨識功能——通常是RoT，來實現通訊和連接的防禦。因此，安全機制和技術應根據終端的具體功能和安全要求進行應用。

虛擬機器將應用程式隔離在各自的區域中，但無論是裸機還是在其上運作的客戶作業系統，終端本身都有許多漏洞。

在這種情況下，一個常見的問題是，應透過硬體還是軟體來保護系統。大多數專家認為，從很多因素來看，硬體保護比軟體保護更可取，但主要還是因為硬體具有更高的防篡改能力，可以提供比軟體更高的信任度和安全性。

很多大型晶片供應商都提供某種硬體級安全保護，可能是可信任平台模組(TPM)或安全元件(SE)這樣的硬體安全模組，也可能是其他形式的系統單晶片(SoC)嵌入式安全功能。其主要目標是實現強大的使用者身份鑒權和驗證，以防受到攻擊，並防止對機密或敏感資訊的非法訪問。

安全元件

硬體安全解決方案的關鍵要素是安全元件，它儲存經過加密的唯一辨識碼，以實現認證保護，確保讀取安全載入憑證。例如，提供物聯網裝置的大規模註冊，確保只有授權裝置才能訪問系統或雲端服務。大多數晶片供應商提供的安全元件都是微控制器(MCU)的一部分，同時還提供某種監控和身份管理系統。

意法半導體(STMicroelectronics)的STSAFE-A110可以整合到物聯網裝置中，為本地或遠端主機提供身份驗證和安全的資料管理服務。該元件具有嵌入式安全作業系統，並採用通過「資訊技術安全評估共同準則」(Common Criteria for InformationTechnology Security Evaluation，簡稱「共同準則」、Common Criteria或CC)評估保證等級5+ (Evaluation Assurance Level 5+，EAL5+)認證的硬體，每個元件都內建唯一標識和X.509證書，以實現裝置的安全連接。這個安全元件與STM32Cube開發生態系統整合，可快速應用於需要身份驗證和安全連接的新型STM32 MCU設計。

恩智浦半導體(NXPSemiconductors)的EdgeLock SE050 Plug and Trust安全元件系列是另一款開箱即用的物聯網裝置安全元件，無需編寫安全程式碼，可提供晶片級RoT以實現端到端的安全性。該產品通過了Common Criteria EAL 6+認證，可提供更好的安全性，作為即用型解決方案，它包含完整的產品支援包，可以簡化設計。

除了提供適用於不同MCU和MPU的庫之外，恩智浦的產品支援包還提供與多種常見作業系統的整合，包括Linux、Windows、RTOS和Android。該支援包包括主要應用的樣本、大量的應用說明，以及用於i.MX和KinetisMCU的相容開發套件，以加快最終的系統整合。其產品配置支援物聯網安全應用，例如感測器資料保護、物聯網服務的安全訪問，以及物聯網裝置調試，是對現有應用的補充，如雲端服務的安全實施、裝置到裝置的身份驗證、裝置完整性保護和證明，以及裝置溯源和來源證明。

英飛凌(Infineon)的OPTIGA TPM系列產品也包含了多種安全控制器，用於保護嵌入式裝置，以及系統的完整性與真實性。OPTIGA TPM SLM 9670是一款高品質的TPM模組，它採用防篡改安全MCU，適於工業應用。作為一種即用型解決方案，它具有安全編碼韌體，滿足最新的可信賴運算組織(TCG) Family 2.0規範。其產品符合工業JEDEC JESD 47標準品質要求，並通過了Common Criteria EAL4+安全認證。

開發人員可以採用OPTIGA TPM來儲存私密金鑰，配合Sectigo身份管理解決方案，可為工廠提供完整的自動化證書頒發和管理解決方案。

瑞薩電子(Renesas Electronics)於2019年10月推出針對安全、可擴展物聯網應用的RA系列MCU。該系列產品採用開放式軟體平台，客戶能夠透過與眾多廠商合作或利用現有傳統軟體平台來開發物聯網終端。瑞薩電子將強大的RoT整合到硬體中，使其成為MCU的組成部分，安全功能的實現因此變得輕而易舉：客戶在完成設計後無需再考慮如何增加安全性。

記憶體內(In-memory)安全

隨著系統越來越依賴外部NOR快閃記憶體來保護連網系統的程式碼和資料，在記憶體中增加先進加密安全性的需求也在增長。隨著快閃記憶體移出主處理器，幾家公司提供了能夠保護快閃記憶體本身的功能(因為無法再將其嵌入到MCU中)，為設計工程師提供了更大的靈活性。例如，英飛凌最近推出了Semper Secure，作為其SemperNOR快閃記憶體平台的補充。

同時，美光(Micron)的專有技術Authenta將NOR快閃記憶體與系統級硬體RoT結合。快閃記憶體本身內建的安全功能可透過晶片RoT實現先進的系統級保護，而無需添加新的硬體。它具有強大的內建加密身份，透過現場更新和始終開啟(always-on)的韌體監控，簡化了從供應鏈到裝置入網的安全裝置管理。

美光2019年10月推出了Authenta金鑰管理服務(KMS)平台，可為多種工業應用提供雲端優先部署模型。採用該平台以後，已安裝Authenta的裝置可以透過雲端服務開啟，從而降低了保護連網裝置安全性的難度和複雜度…

附圖：圖1：IIC的工業網際網路安全架構(Industrial Internet Security Framework)中確定了終端各個部分的威脅和漏洞。
(來源：IIC)
圖2：TPM透過其獨特的背書金鑰和金鑰分層結構來支援金鑰及生命週期管理。非揮發性記憶體可用於安全儲存敏感性資料，例如證書，它基於防篡改硬體，安全功能包括感測器和記憶體加密功能，以增強對機密的保護。(圖片來源：英飛凌)

資料來源：https://www.eettaiwan.com/20210125nt51-protecting-the-endpoint-in-iiot-a-snapshot-of-chip-level-security/

TL;DR

如果發現 hbase shell 在 scan 或 count 的筆數與你預期筆數不一致的話，就 split region 看看吧。

--- 以下是前言，還真長 XD ---

最近都在忙著新版本上線，所以小編也好一陣子沒發文了。不過這幾天有個有趣的案例，想跟大家分享一下。

有在看小編文章的大概會知道我們產品的資料庫是以 HBase 建置而成的，而 HBase 最重要的組成就是 rowkey 了。若 rowkey 設計錯誤輕微可以使用 column 來救，嚴重的甚至要砍掉整筆 row，重新設計 rowkey 才能解決。

兩年前在設計某 table 的 rowkey 時，不小心忘了對 rowkey 做 salt (HBase 基礎之一，避免 scan 時產生 hotspotting)，如果又沒切 region 的話 (HBase 基礎之一，避免 scan 時產生 hotspotting)，這些資料在建立時都會跑到同一個 region，在 scan 的時候效能會超差。

像這種例子就算使用 column 來救也完全沒辦法，所以小編就打算把整筆 row 砍掉重新把 salt 加上去。

--- 以下是追蹤過程 ---

原 rowkey 開頭及加上 salt 之後的新 rowkey 開頭如下：

* 原：A000001、新：DNhA000001
* 原：A000002、新：dMfA000002
* 原：A000003、新：p9OA000003
* 以此類推

原 rowkey 相同 pattern (A000XXX) 的 row 有 2000 萬筆 (在 hbase shell 內使用 count 來計算 table 的資料量)，所以這次 rebuild 總共會刪除原 rowkey 共 2000 萬筆，新增新 rowkey 共 2000 萬筆。

在使用 HBase 的 Java API 執行增刪 rebuild 後，在 hbase shell 使用 count 計算 table 的資料量時卻只有 900 萬筆。一開始小編還以為是 compaction 跟 flush 的問題，所以強制對 table 做了下面幾個動作，以確保資料有在 HFile 裡面正確地寫入及刪除：

* 確認資料都會刪除：compact、major_ compact
* 確認資料都會寫入：flush

但執行完後再跑一次 count 也是一樣只有 900 萬筆，所以就開始找問題點了。

後來又使用 HBase 的 exists API，確認有找到 2000 萬筆的資料。一開始小編以為是 MapReduce 的問題，因為 HBase 計算 row count 是使用 MapReduce 來執行的，但找了一堆資料都沒人說有類似問題。後來想說在 hbase shell 內使用 scan {COLUMNS => "cf:XX"} 將所有的資料都拿出來，發現也是只有 900 萬筆，所以初步排除是 MapReduce 的問題。

後來比對了新增的 rowkey 及目前 scan 出來的 rowkey，發現 scan 出來的 rowkey 只有到 GbVA000017 而已，後面的 H-Z、a-z 開頭的全部都沒出現。所以小編使用 hbase shell 的 get 指令，確認在 Java API 新增的 rowkey (A-Z、a-z 開頭的) 是否存在於 table 內，發現用 get 可以拿的到資料。討論後用 scan 加 start rowkey 試試，結果如下：

* STARTROW => "GbVA000017"：只找到一筆
* STARTROW => "H"：可以找到 H 之後的所有資料

看了這結果，真的覺得非常奇怪啊！！！

後來大神 Cowman Chiang 說要不要試著用 split 讓 HBase 重切 region 看看，等於是 rebuild region 的意思，因為 split 會使用字母順序切分成不同的 region，讓 row 重新分散。split 完之後再做一次 count 果然就找到 2000 萬筆資料了啊。

感恩 Cowman Chiang 讚嘆 Cowman Chiang！！！

--- 以下是結論 ---

目前看起來就是 region 發生異常，還不知道是什麼原因會造成這次事件的發生。但如果發現 scan 或 count 的筆數與你預期的內容不一致的話，就 split region 看看吧。

--- 本次追蹤使用工具 ---

* Linux: grep, cat, cut, sort, sed, comm, wc, less, head
* Java: exists, scan, get, put, BufferedReader
* hbase shell: snapshot, split, compact, major_compact, flush, restore_snapshot, scan, get, disable, enable, clone_snapshot, list_snapshots

--- 20180112 後記 ---

後來把 snapshot 還原之後，重新做了一次 rebuild 再做 count，結果還是一樣只有 900 萬筆，然後用 hbase hbck -repair 試著看看是否能把 region 修復 (有 4 個 inconsistencies)，修復完後一樣是 900 萬筆。

也有同事說到會不會是資料塞太快的關係，造成 region 無法 split 完整才會發生這個問題。對於這個說法，小編也還在研究看看，有什麼進度會再分享給大家知道。

#hbase #hadoop #mapreduce #hotspotting