物聯網安全 物聯網與虛實整合應用之安全.

Presentation on theme: "物聯網安全 物聯網與虛實整合應用之安全."— Presentation transcript:

1 物聯網安全 物聯網與虛實整合應用之安全

2 大綱 虛實整合(行銷)應用的概念與主要模式 虛實整合與物聯網技術的結合 虛實整合應用當中的主要物聯網元件 虛實整合應用物聯網元件安全 結語

3 虛實整合與物聯網應用(1/2) 虛，一般是指線上(Online)，按照維基百科的定義，是指連上網際網路的狀態[1]
實，通常指的是離線(Offline)，通常是只沒有連上網路的實體通路 其中一種應用就是離線商務模式(Online to Offline, O2O)，在網際網路上進行行銷，而將使用者導到實體商店進行消費[2] 例如團購，就是在網站上聚集而有量的優勢，並據此向商店議價取得優惠，進而在實體商店購買 [1] [2]

4 虛實整合與物聯網應用(2/2) 物聯網技術可進一步逆轉線上到線下的模式，而重新讓使用者可透過實體的物件去導到相關的線上服務消費
韓國的Homeplus(Tesco)，在地鐵站貼QR Code，讓使用者看到商品圖案後可以掃描條碼進行線上購物，之後送貨到府[3] 美國eBay包下多間百貨公司櫥窗展示商品，有興趣的使用者可掃描條碼購物[4] La Comanda推出Click’N’Pizza磁鐵，想吃Pizza時只要按下磁鐵上按鈕就會線上自動訂Pizza並送貨到家[5] [3] [4] [5]

5 虛實整合行銷的四種主要模式 目前談O2O，多半著重在行銷領域，而有以下四種模式： Online to Offline
代表應用是團購，交易行為在線上發生，而客戶到實體商店或線下去享受服務或取得商拚 Offline to Online 在實體商店提供網路(線上)交易的折價券，因而吸引使用者到線上繼續消費 Offline to Online to Offline 使用者在實體通路取得折價券，因而到線上消費，而線上交易又會將使用者導到實體商店進行消費。例如使用行動支付消費後送購物點數，之後可再用此點數去買實體通路的折價券去實體通路使用 Online to Offline to Online 和前者類似，指的是線上購買實體商店的產品或服務，消費後在實體商店獲得點數或折價券，而讓使用者可在線上繼續交易 基本上是以Online to Offline與Offline to Online兩種模式為基礎，因而持續循環

6 虛實整合技術常與 基於地點的社交網路技術結合[6]
基於地點的社交網路技術(Location-based Social Network, LBSN)是指在社交網路當中，使用者可以分享自我所在的地點 透過LBSN的技術，使用者可以提供自己所在地點的相關資訊，並且將訊息透過社交網路分享，甚至可以搜尋鄰近的朋友，共同去進行某項活動 近來許多虛實整合的行銷應用，也多半會結合LBSN平台 [6] Tao Zhou, Jiuxin Cao, Bo Liu, Shuai Xu, Ziqing Zhu, and Junzhou Luo, Location-Based Influence Maximization in Social Networks, CIKM’15,October 19–23, 2015, Melbourne, VIC, Australia.

7 擴增實境與虛實整合行銷的結合 擴增實境技術可以增加虛實整合的應用體驗
擴增實境(Augmented Reality, AR)技術是一種將影像進行處理，而將虛擬世界當中的圖像計算好位置後加到影像中合適的地點，並進而加加入虛擬圖像的影像作呈現的技術[7]。 像是樂天的AR-HITOKE計畫[8]，就是讓客戶在看到商場地圖時，就可以知道各商店的活動與人潮聚集的狀況。而將手機對準商品，就可以得到商品的介紹和過去購買該商品的人數與使用體驗等資訊。 [7] [8]

8 虛實整合應用中的主要 物聯網元件(1/2) 位置參考點 消費者 實體商店 智慧裝置 店員 能和使用者手機溝通之收銀機或智慧裝置 後臺服務

9 虛實整合應用中的主要 物聯網元件(2/2) 智慧型手機扮演使用者使用線上與線下服務的重要媒介
智慧型手機可用做線上交易使用 智慧型手機目前是許多線下交易的付款工具 線上交易購買的折價券，可透過智慧型手機傳送給商店 商店的購物折價券或收據，可以傳送到使用者手機而供使用者後續使用 作為結合AR、LBSN等技術的裝置 物聯網裝置(如iBeacon)提供室內定位的資訊 後臺服務，例如 可結合外部服務(如社交網路)做更進一步的推銷 交易時會需要透過相關的交易後台 票券的儲存與驗證平台 廣告推播平台

10 可依虛實整合應用中物聯網的元件 分別評估安全考量
參考點安全問題 智慧型手機端應用程式的安全與隱私問題 智慧型手機與實體商店裝置進行資料交換的安全問題 使用後台服務的安全與隱私問題

11 以iBeacon為例看參考點安全問題 0. iBeacon使用BLE技術，廣播本身識別訊號 用以識別所在分店 預設訊號強度 主要的ID
UUID(16bytes) 2bytes 2bytes 1byte 用以區別分店中的不同 iBeacon 3. 後臺服務提供相關折價券等資訊 消費者 智慧裝置 1. 取得鄰近的iBeacon識別碼 2. 向後台服務告知鄰近iBeacon 的識別碼 後臺服務

12 目前一般可用手機模擬iBeacon 在使用 Android 撰寫以下程式，可獲得鄰近 iBeacon 訊號
private final ScanCallback startScanCallback = new ScanCallback() { @Override public void onScanResult(int callbackType, ScanResult result) { ScanRecord mScanRecord = result.getScanRecord(); byte[] content = mScanRecord.getBytes(); int flag = mScanRecord.getAdvertiseFlags(); int mRssi = result.getRssi(); } }; 以此設圖情境為例，獲得訊號為： [2, 1, 26, 26, -1, 76, 0, 2, 21, 82, 65, 68, 73, 85, 83, 78, 69, 84, 87, 79, 82, 75, 83, 67, 79, 0, 12, 0, 45, -56]

13 偵測iBeacon造假的策略 後臺伺服器要求使用者傳送目前所在位置，比較收到的iBeacon識別碼與使用者所在位置間的關係
除了識別碼之外，BLE廣播還會同時傳播藍牙裝置的MAC位置。因此可以透過比對MAC位置與相對的識別碼去驗證 缺點：接收到廣播時，也會收到裝置的MAC位置，因此可以據此去偽造MAC位置製作偽造的iBeacon 透過BLE Privacy等的技術，讓MAC位置會隨著時間變化，而只有持有金鑰的人才能還原 缺點：不見得所有的iBeacon都支援BLE Privacy

14 智慧型手機端應用程式的 安全與隱私問題 如果智慧型手機的應用程式如果有弱點，可能會造成交易錯誤或是使用者資料被盜用
在開發時應避免常見的安全問題(可參考如OWASP行動十大弱點) 可參考市面上的最佳實務進行手機應用程式的開發(如ENISA所提供之供應用程式開發主之智慧型手機安全指引(Smartphone secure development guidelines for app developers))

15 ENISA–供應用程式開發主之 智慧型手機安全指引(1/2)
識別與保護行動裝置上的敏感資料(Identify and protect sensitive data on the mobile device) 安全地處理裝置上密碼等資訊(Handle password credentials securely on the device) 確保敏感資料在傳輸時有被保護(Ensure sensitive data is protected in transit) 正確的實作使用者身分鑑別、授權、與連線管理機制(Implement user authentication and authorization and session management correctly) 確保後台API與相關平台安全(Keep the backend APIs (services) and the platform (server) secure) [9]

16 ENISA–供應用程式開發主之 智慧型手機安全指引(2/2)
與第三方應用與服務進行安全的資料整合(Secure data integration with third party services and applications) 特別注意個人資料的收集與使用(Pay specific attention to the collection and storage of consent for the collection and use of user’s data) 對於會需要付費的資源進行控制以避免未經授權存取(Implement controls to prevent unauthorized access to paid-for resources) 確保行動應用程式的安全發布與提供(Ensure secure distribution/provisioning of mobile applications) 仔細檢查執行過程中所發現的錯誤(Carefully check any runtime interpretation of code for errors)

17 ENISA–其他開發安全議題(1/2) 執行對誤用案例的測試(Perform abuse case testing)
對所有輸入進行驗證(Validate all input) 想辦法降低程式碼的複雜度(Minimize lines and complexity of code) 使用考量安全的程式語言(Use safe languages) 實作安全通報方式(Implement a security report handling point) 使用工具以發現安全弱點(Use static and binary code analyzers and fuzz-testers to find security flaws)

18 ENISA–其他開發安全議題(2/2) 使用安全函數(Use safe string functions)
以最小權限執行應用程式(Run apps with the minimum privilege required for the application on the operating system) 使用不同角色執行測試(Always perform testing as a standard as well as a privileged user) 避免在使用者端開啟通訊服務(Avoid opening application-specific server sockets (listener ports) on the client device)

19 針對虛實整合應用之特殊考量─ 對於機敏資料的保護(1/2)
識別重要資料並加以保護，重要資料像是： 使用者的卡號的金融資料 使用者的其他個人敏感資料 認證用金鑰 必要時可考慮使用硬體對重要資料做保護： 例如Apple Pay或Android Pay只有儲存在安全元件(Secure Element, SE)卡當中的應用程式才可以啟動NFC功能將手機模擬成信用卡做支付

20 針對虛實整合應用之特殊考量─ 對於機敏資料的保護(2/2)
金鑰的產生必須符合產生規範 使用被驗證的金鑰演算法 如果使用非對稱式金鑰技術，私鑰應在本地產生 部分金鑰資訊可來自於使用者個人輸入的PIN碼 避免所有應用程式使用同樣的金鑰 將受害的影響降到最低 評估到底有哪些資料要存在本地？哪些資料要存在後臺服務？ 存在本地的好處：存取速度快，網路斷線也可使用 存在本地的考量：有可能被破解或竄改

21 針對虛實整合應用之特殊考量─ 應用程式設計的安全考量
金鑰不可以存在程式碼當中，避免被用程式反組譯而獲得 在安裝前可進行環境安全檢查，如手機是否有被破解，以及其他應用程式可以繞過手機的安全機制？ 可以檢查並要求使用者安裝惡意程式檢查工具 儘可能避免將機敏資料寫入記錄檔等位置 使用安全連線時要檢驗憑證，避免中間人攻擊等問題 收到跨程式間訊息時，要檢驗訊息來源與正確性 儘可能減少敏感資料在記憶體當中的時間 使用完之後要把變數釋放

22 針對虛實整合應用之特殊考量─ 後臺服務認證的安全考量
減少身分鑑別金鑰的使用次數，在身分鑑別完成後可以採用限定時間使用的交談金鑰(Session Key)，或是存取權杖(Access Token) 應用程式端要妥善保護交談金鑰或存取權杖 在使用者初次啟用應用程式時，可以使用第二管道(如簡訊或 )，確認使用者身分 因為應用程式可能被反組譯而將存取協定破解後送出假造的要求，因此需要一般重要的存取要求最好在後台做檢查

23 識別跨程式訊息的正確性與來源 減少在記憶體當中儲存機密資訊的時間 私鑰要經過加密保護，且加密使用的金鑰不可存放於程式當中 要確認對方憑證的有效性 識別重要資料並加以保護 善用 Session Key 技術，減少金鑰被破解的機會 行動應用程式 私鑰/ 憑證/ 資料 善用 Out-of-Band 的方式對使用者進行更進一步的身分鑑別 後台服務 適度使用硬體保護 公私鑰對與憑證的產生要符合安全原則 判斷要在後台執行

24 智慧型手機與實體商店裝置進行 資料交換的安全問題
使用者可能讀取被置換的QR Code，因而連接至錯誤的網站，或是取得錯誤的資訊 傳輸的資料被竊取 有讀取器暗中讀取使用者識別資訊 被服務阻斷攻擊 訊號轉傳攻擊(Relay Attack)

25 使用者可能讀取被置換的訊息 主要發生背景 問題範例 解決建議
使用者使用智慧型手機，並且運用NFC或是鏡頭，讀取商店當中的NFC/RFID或是二維條碼，因而連至其他網站或是取得折價券 問題範例 標籤或二維條碼被置換，以至於使用者連接到木馬網站或是被進行插碼攻擊等 解決建議 在標籤資訊或是二維條碼中加入簽章或驗證資訊，以便取得資訊的使用者可以驗證

26 傳輸的資料被竊取 主要發生背景 問題範例 解決建議
使用者使用手機將票證或是其他資訊透過無線傳輸方式傳送給商家，或是商家將折價券透過無線傳輸傳給使用者 問題範例 傳送的訊息被竊取，機密資料被外洩 解決建議 運用傳輸媒介所提供的安全通道或是自行進行資料加密 例如早期電力線(Home Plug)傳輸沒有加密，因此很容易可以竊取同一線路上傳輸的資訊，現在相關產品多半支援AES-128加密 另一個解決方法是安裝掃描工具，以發現未經授權的訊號讀取器

27 有讀取器暗中讀取使用者識別資訊 主要發生背景 問題範例 解決建議 當使用者持有RFID標籤或是做為iBeacon廣播識別碼
惡意攻擊者單純使用讀取器被動收聽廣播資料，因而可以追蹤特定識別碼物件的行蹤，從而追蹤到相關使用者的行蹤。 解決建議 進入特定地點關閉廣播功能 使用前述之BLE Privacy類似功能，定期變更自身的識別碼，而只讓有獲得授權的人能夠分辨

28 被服務阻斷攻擊 主要發生背景 弱點範例 解決建議 使用者使用無線方式和商店的裝置進行資料交換
被攻擊者針對特定頻段發送訊號，致使正常通訊無法進行 解決建議 使用偵測工具，以掃描和發覺阻礙通訊的訊號源

29 被訊號轉傳攻擊 主要發生背景 弱點範例 解決建議 使用者使用手機或感應式卡片和商店進行交易
使用者的手機連接的是惡意攻擊者的讀取器，而惡意攻擊者將此訊號傳送至遠端攻擊者的手機，而用使用者的身分進行交易。 因為惡意攻擊者的讀取器扮演的只是訊號轉傳的動作，因此不需要知道訊號的內容也可以完成交易 解決建議 限制交易完成時間，以避免類似攻擊的發生

30 使用後台服務的安全與隱私問題 有關後臺服務應用程式的安全問題可參考OWASP十大安全弱點，避免程式具有相關的安全弱點
如果會透過使用者手機連結到社群網站，社群網站建議建立以下安全與隱私保護機制： 當商家要取得使用者資料，確定使用者有被告知並且取得使用者同意 避免商家的手機應用程式直接取得使用者登入社群網站的帳號與密碼，因為商家可能會將此資訊外傳。最好的方式是另外在使用者手機建立該社群網站的登入應用程式，在使用者完成登入並同意提供資料後，將存取權杖交給商家的應用程式，並讓商家的應用程式用此向社群網站進行存取

31 結語 物聯網可帶來虛實整合行銷的許多新應用，更可與社群網路、擴增實境等技術做結合而擴展行銷效果 然而這中間也會帶來許多安全問題：
如果使用參考點來判斷使用者位置，要解決參考點被偽造的問 智慧型手機端應用程式的開發上，要特別保護機敏資料的安全，並且要做好確認訊息來源的動作 智慧型手機與商店的裝置進行資料交換時，要確保資訊的來源正確性，並且要保護傳輸訊息的機密性 如果跨服務提供資訊，或是讓商店的應用程式存取使用者的社群網站資訊，則需要確保使用者表示同意，並且避免其他應用程式取得使用者對於社群網站的身分鑑別資訊