Note:基本加密連線隨想

本來就有在想要怎樣做安全的交換資訊, Google等公司很早就啟用了two-factor的驗證, 本來基於我粗淺的密碼學認識就是, 在設備內存一個hash init vector, 然後透過時間區段去做特定HMAC就可以得到一個隨時間變化的驗證碼, 只要保管好這個init vector就可以簡單作到相關應用, 這個key應該被存在 TEE的環境中,在Android 應該是Keystore 機制來實施, 可能的話, 顯示的UI也許也是要TUI(Trust UI)

設計一個安全的IoT系統基本上就是要有一個可靠的系統存放各種KEY(HASH), 目前可見TEE環境與TPM, 或是各種嵌入安全晶片會越來越多

交換資訊時, 需要驗證的地方需要加入Timestamp/DeviceID 當作salt 這樣可以避免 Capture/Replay 通訊封包就侵入系統, 這樣做的目的是該封包, 等於該時該裝置才能解密後檢驗有效. 再加強的話就把連線雙方資訊也加進去。

今天早時間看了一下Google Authenticator 看起來是透過這樣的方法實作出來的
TOTP (Time-Based One-Time Password Algorithm)
HOTP (An HMAC-Based One-Time Password Algorithm)

https://tools.ietf.org/html/rfc6238
https://tools.ietf.org/html/rfc4226

廣告

Note: 智慧眼鏡(Smart Glass) 發想

目前智慧眼鏡開始進入企業商業應用範疇, 但是有一些降低成本需求的聲音某些時候只是為了有一個屏, 輔助使用者再某些情境的應用, 因此考量該需求會希望降低該眼鏡成本, 而且需要長時間的使用, 開始有一種攜帶式裝置搭配電源採取連線的設計

個人看法這應該可以直接採取 USB-Type C 透過Alt DisplayPort or HDMI直接傳送影像的設計,這樣可以大幅減少成本, 然後為了標準開放的話,可以跟USB  協會提案一個新的profile, 透過USB Device configuration 可以回傳眼鏡本身的硬體特性, 如EDID或是影像成像相關校正特性矩陣, 因為對於攜帶裝置來說只是加上一層幾何變換處理當GPU夠強大時可以直接套用, 做AR/MR時可以再疊一層Overlayer 設計

有鏡片焦距資料/形變矩陣/投影大小, 系統也可以自適應的調整對應UI 這樣才能更完美推進使用者應用情境

Note: About An e-Seal system design

e-Seal 主要是應用在貨櫃轉口或是由保稅倉庫轉移貨物, 基本上就是要由一個保稅場域移轉到另外一個保稅場域的設計, 傳統有海關派人押運, 後來演變成為封條設計, 近十多年來各國普遍發展出RFID 的電子封條設計

電子封條,主要有兩個部份設計因為是鎖住貨櫃所以有機械鎖的部份, 這部份有ISO 17712機械鎖的國際標準可以遵循, 跟採用RFID電子標籤技術結合的 ISO 18185國際標準
ISO 18185 分為 5個部份, 分別為

  1. 通訊協定, 有433MHz(Type A)/2.4GHz(Type B) 兩個頻段的LRL(Long Range Link),跟低頻的SRL(Short Range Link) 跟資料鍊路層(Data link, L2)的定義
  2. 應用需求, 包含使用情境, 基本需求資料
  3. 耐候環境特性, 包含高低溫, 振動, 外力衝擊, 鹽霧, 濕度, 冰與雨, 熱衝擊, 等等
  4. 資料保護, 定義機械鎖跟電子所的啟閉封安全需求避免被破壞跟仿製電子封條
  5. 實體層, 定義Type A/Type B的實體層設計如OOK/FSK 調變

這上面算是被動式一次性電子封條的需求, 追求的便宜安全, 因為一次性, 但電子封條未起用前成為不可讀, 而讓仿冒的可能性降到最低, 因為會有唯一ID設計, 如果再加上一些貨物相關資料編碼做電子加密後才能啟用, 系統可以設計滾動式亂數密碼, 啟用時寫入電子標籤與上傳系統,進一步杜絕中間被代換的可能性。

目前有看到一個需求主動式電子封條,為了追求更安全的使用情境, 加入GNSS Tracking System 去追蹤貨物運輸狀況

基本的資料應該是一樣的會有電子封條唯一識別資訊, 不同是這種主動式封條本身因為價格問題應該是可重複使用的所以系統設計有些許不同, 基於安全需求為設計為使用一個固化電子憑證儲存,本身唯一資訊, 然後每次使用前應該也是由系統配發一個任務碼進行加封包含相關資料做加密寫入區塊。

加封時須已經完成定位跟顯示相關任務資訊內容待授權人進行確認核可。

加封後應持續發送封條辨識碼, 定位資訊與封條狀態,此時採用MQTT Server 並用SSL加密, 甚或payload 本身採取任務碼與其他特徵為key做AES256 加密, 藉以達成資料安全保密需求防止資料被竄改的可能, 後台採用MQTT後端系統, 可以再發展資料收集系統或是與其他系統相連功能做電子資料交換(EDI)

到達目的地解封時,系統可以採取判斷是否資料有異常特徵,紀錄監管解封狀態等等資料

 

海關推出智慧化電子封條讀取器

“截至今(一○五)年八月底止,以加封電子封條方式取代之人工押運櫃合計三十四萬二千七百九十九只"
據稱現在台灣有接近45萬只貨櫃/年(2018), 從年押運量來看 用200個工作天計算, 一天約需要2200個但是因為不可能達到理想化分配採取x3 約為6600只, 再加上1000餘裕配置, 約估計台灣最多只需要8000只可重複配置的電子封條鎖
不懂進出口關務真的會做出錯誤判斷 😛
就算按照裡面說的不包含需要押運的每天平均車次也才2萬次, 最樂觀看來5萬只就是爆量了

Note: new cv online for learning RWD skill

最近開始學了一下RWD/Web front-end 的內容, 剛好開始找工作, 想說拿之前用別人的版做的resume , 用Google 新的Material Components Web 自己手動復刻了一個版本, 陸陸續續做了一陣子, 目前有一個雛型了 Jekyll-mdc

做這個練習大概會學到一些基本的 CSS3/Sass/HTML5/npm/Webpack/Travis-CI/Github Pages/Jekyll  等相關技術棧與framework的技巧

也遇到了Web 標準這幾年持續演化, 有很多相容性的問題, 發現做Web要養人來堆不是沒道理的

如果是工作的話, 除非變成很熟捻各種技術相容性問題, 不然選成熟一點的方案會好一點, 省點力氣, 當然如果公司有特定目標可以選一些新的發展, 畢竟新技術都是為了解決舊有問題, 只是因為Web標準跟Broswer 支援程度落差不少, 尤其這個現在Browser還是各種新舊版本與相容問題, 問題跟Android 碎片化的情況不遑多讓

隨想: 找工作整理2018

最近休息近半年後開始找工作,越來越體會年老色衰的就職市場劣勢,然後台灣薪資狀況看起來已經無解,當然自己不是大牛也是有關係,自己知道有些缺點,不過自我評估優點應該是蓋過缺點。但是這個要持續工作後才能展現,面試很難單憑口說證明,除非是熟人介紹。

目前手上只有兩個選擇,一個是某工控廠商,一個是某BIOS IBV,不過面試的部門是BMC部門。

兩個目前開出的薪資相近,IBV的月薪是工控+5K,但是工控保證的年薪數字略高,但是估計兩邊我最後獲得的年薪應該差異不大。所以想分析一下選擇哪邊對自己有利。

公司未來前景:

工控廠商看起來產品毛利率有下滑的趨勢, 不過這應該不算大缺點,目前台灣系統廠商普遍有這方面的問題,看了一些相關報導,高層有意識到工控業界會愈來愈零碎化,因為競爭者眾,不再如我10多年前,做標案時沒選擇性,必須要自己從工控的標準品去客製化,現在的局面走向高度面向行業領域,因為競爭者眾大家都想從工控市場分一杯羹,變成工控廠商如果不殺價錢就要面對應用領域去推出應對產品,所以相對會越來越零碎化,簡單講已經到了必須如同IC vendor 的Turnkey services;再付出越來越多的客製化能量,這有賴於市場與業務的手腕去爭取客戶付費在這客製化,不然毛利率只會一降再降,目前看到的是市場還願意付費在這個區塊,因為能提供好的客製化服務的廠商還不太多,還沒到完全紅海的競爭局面。 不過市場上目前充斥很多只願意付國產車價格但嘴裡卻要超跑性能的客戶, 但是不能分辨客戶剛需的業務與PM,往往會用這個理由替業績不佳開脫。該公司目前也是效仿其他公司開始展開策略聯盟或是購併來擴大市場規模避免邊緣化並補齊產品線。

至於IBV 目前看起來公司整體來說市占率還是最大,從投資面看起來算是有市場護城河,不可能大起大落,算是不用擔心公司前景。

個人技術發展前景:

工控廠商–目前想找的是一個做遠端管理方面軟體的人,目前目標是Windows 10 IoT Core,但是也要維護舊有的 Windows Embedded Compact 產品跟舊的配合iAMT的軟體。按照說法應該是想改版上UWP, 不過這個我估計要再2年左右才會真的進入市場或是根本不在市場上,為啥這樣說是因為,UWP Mode 的App 實際上,開始支援跟硬體相關資訊的存取要到Windows 10 1803 開始才有,當然實際上應有其他Work around的方式,應該可以透過操作界面是UWP,但是實際Control 透過Services 之類的方法。對我來說可能可以獲得的成長性是,Windows Driver/BIOS與互動的可能性,這大概10年前就有投入相關學習,不過礙於公司狀況,一直不適合推動,因為有部門職責問題,還有企業文化等相關問題。人的問題往往比技術問題更難解決。
唯一問題是Windows 10 IoT Core 會不會被Microsoft 之後放棄,目前趨勢看來不無可能,估計再經過2, 3年,如果相關市場上無法取得一定成果,被放棄的機率大於70%,畢竟Microsoft 已經採取新的戰略方式 Azure Sphere 都推了。如果發生就是等於把時間投入一個將死的技術堆棧,不過如果拉長來看,這世界技術堆棧死的不計其數,但是領域知識總是大同小異的。而且本身不是只會Windows 相關技能,對於我來說切換技能樹相對簡單。

IBV–目前提供的是Team leader,要負部份管理職責,做的是基於Debian 的BMC BSP Porting相關工作,還有支援某些未來功能需求,目前看來這部份的工作因為職責與公司的知名度關係,會對個人履歷有點加分作用。不過技術堆疊應該就是持續再BMC相關開發上面,估計可以做個3~5年。

工時與通勤距離長短:

目前看起來兩家公司都是正常工時,不太會有超時工作的需求。如果考量通勤,工控廠商位於我步行可達範圍算是加分,IBV要搭捷運30~40min.,但上班時間更彈性點。

目前最大問題是之後還想不想在求職人手市場上打滾,拿別人飯碗的問題。目前看來如果還要再換公司應該選IBV會好一點。但是這個不是我的剛需,畢竟年紀真的到一個程度,市場很現實。

個人成長方面

個人目前有開始學習Full stack 相關知識方面,如果要應用相關內容,則工控廠商的機會大於IBV,不過這會回到公司文化跟人的問題。這在未入職的階段無法確認,目前只有透過朋友去打探一下該公司該部門狀況,得到的答案是該部門還算正常,台灣工控內部搶人搶資源的內鬥情況蠻嚴重,生為一個技術宅,很容易被影響。

Note: IOTA with Industry 4.0 的一些想法

最近在看IOTA 的一些東西,今天早上突然有個想法是應用IOTA 的帳本紀錄在工業4.0上面,假設有個工廠想要導入IOTA相關技術到生產管理上面,實際上需要建立一個或多個Full Node 目前IOTA提供的參考實作 IRI 是透過JAVA EE 寫的,個人覺的他有一個缺點是JAVA EE 本身需要比較大的計算資源,可能的話我個人覺的是在工廠的生產場線場景,透過各種IoT Gateway 執行這個Full Node 功能,這時選擇比較輕量架構應該是一個降低整各應用場景成本的,例如用Python/Go/NodeJS/Rust 等等語言去實現這個FullNode

而考慮應用場景的後續管理維護問題Full Node 與IOTA Devices(Wallet)也需要應用上 Neighbour Discovery Protocol,這樣才有可能達到快速佈建與減低後續維護管理的成本。

再來IOTA Deivce需要自動產生 Seed 並且隔離在應用層,這個應該可以應用目前 Trust/App OS 分離的設計,透過MPU/Hypervisor/TrustZone … 等等技術去隔離

當然以上是考量用比較小的成本去執行,昨天還看到對岸某各機器人公司用ROS做的設備那些東西的成本可以忽略執行IRI成本,但是考量後續管理維護成本其他東西還是需要補齊,考量初始裝設成本跟後續維護成本的比例實際上這裡初始裝設只佔比較小的部份

 

Note: 痛點/爽點/癢點–梁寧–產品思維

“梁寧–產品思維" “得到"上的一門課 目前售價 RMB 99
其中的一篇試讀 10 痛点、痒点、爽点都是产品机会

今天看到有人推薦, 試讀了一下感覺還不錯 但是不知道為啥在我的電腦上無法直接撥
只好看一下他的網頁 找到是mp3 檔案  (另外一篇試讀課)可以透過瀏覽器直接播放
這堂課談的是面對客戶的產品需求定義要如何透過一些方式找出來,文內定義了三個面向,分別是

  • 痛點 — 對應解決客戶心中恐懼害怕的問題
  • 爽點 — 對應客戶當下產生怎樣的需求,就能立刻處理短時間內解決,滿足客戶
  • 癢點 — 對應客戶心中的理想投射,客戶期望的各種事物,提供一個滿足想像的方式