# [IOT Access control and Authentication Management via blockchain/June 2018](https://www.researchgate.net/profile/Khaled_Salah7/publication/325819533_IOT_Access_control_and_Authentication_Management_via_blockchain/links/5b2794db0f7e9be8bdaebaea/IOT-Access-control-and-Authentication-Management-via-blockchain.pdf?origin=publication_detail)
> In book: Internet of Things – ICIOT 2018, pp.150-164
> Author:Abdallah Zoubir Ourad, Boutheyna Belgacem, and Khaled Salah
> IoTセキュリティ

* 使用這個機制主要去確保使用IoT服務的IP經過使用者授權
## introduction
* IoT數量指數型的成長
* IoT comment access control
* ABAC (Attribute-based access control) and RBAC (Role-based access control)are proven to be infexible, unscalable and difficult to upgrade
* BLOCKCHAIN
* 介紹event log
* 智能合約的自主性，而不受第三方控制
* IOT 沒有做好好的Access control或安全防護而導致安全的問題，如DDoS攻擊
* Securing access to IOT devices produces a Scalability problem.
* 若device各個需要獨立的憑證時，擴展性會是很大的問題
## Literature Review
### 2.1 IOT authentication traditional models
* OAuth2-IoT
* 基於高度信任的第三方，來授權user使用IoT資源，一方面減少IoT消耗大量成本來做權限驗證的機制
* On the other hand, trusting a centralized entity increases the threat of having a single point of failure which threatens the availability of the presented approach
* 網路釣魚非常可能導致這種模式的失敗

* OAuth0
* 提供一個透過ETHEREUM授權伺服器的機制
* 他還是需要3rd party authentication server
* 大概佔整個operation 的62.5%
* **Blockstack** is presenting the concept of a new decentralized INTERNET.
* 系統利用用戶的密鑰對以與PKI類似的方式進行身份驗證
* 驗證成功後，系統生成JSON Web Token(JWT)來存取之後的服務
* 缺點
* 所有應用都要使用blockstack browser，如果不是blockstack app should be installed on the user’s machine

## 3. Systems Design and Architecture

* To implement such solution, the following assumptions must be taken into consideration:
– The user owns one or more IOT devices.
– The user’s Ethereum keystore is not compromised i.e. the private key is
protected.
– The user has an Ethereum account.
– The user and the IOT device are connected to the Ethereum blockchain
– The user will deploy his smart contract.*
> *由於這個paper著重在去中心化的應用，雖然智能合約也可以由中心化組織部署，但若user能夠自己部署自己的合約的話，才能達到去中心化的核心價值。


圖片詳細流程介紹
1. 用戶使用他的以太坊錢包地址對智能合約進行身份驗證。
2. 如果用戶有效，則智能合約會廣播Access token和the sender’s ethereum address。用戶和物聯網設備從智能合約接收廣播信息(event)。
3. 用戶將Access token, User IP, Access duration and the ethereum public key 打包後加上public key送出。是否將包裝加密是可選擇的，但是在這裏爲了確保資料完整性所以選者加密。/The user crafts a package that contains (Access token, User IP, Access duration and the ethereum public key). This package is signed using the ethereum private key then sent with the corresponding public key. The package can be encrypted if wanted. However, It is not required for the protocol to operate. Integrity is what matters in this scenario hence the signing of the message.

4. When the IOT device receives the package, it checks the following:
– If both received public keys are similar.
– If the signed message was genuine.
– If the public key belongs to the Sender’s Ethereum address.
– If the Access token is valid
– If the IP in the message is similar to the sender’s IP
若驗證成功，IoT則授權對應IP的存取權限，反正，the request is dropped.

## 4 Implementation and Deployment
> 將實作劃分為兩塊：智能合約與User-IOT interaction，這樣不僅易於debug，也已於開發過程
### 智能合約

**流程介紹**
* 部署合約者才是合法的單一用戶(admin user)
* addUser()
* 增加更多user的權限
* logic_admin:呼叫來執行驗證
* 呼叫rand()來產出隨機的hash
* 透過hashing user的地址，block time，與前一步產出的hash來產出token
* 最後將token與user的地址一起傳送給user與IoT

### User-IOT interaction
> 此時user與IoT皆已收到token與user的地址之event
> 在這個範例的前提是user必須知道Device的address IP活domain name
> 若非如此，Device address必須要由event傳送

#### User side implementation flow:
* 用nodejs 與 web3來監聽Event

* 確保收到event中的sender address與本地端所保存的keystore中提取的address是一樣的
* 使用keythereum技術來存取私鑰
* 使用elliptic技術來存取公鑰
* 當確保Event中的msg.sender符合本地端的之後，開始打包授權信息(1)

以下爲符號解釋
* 最後，將以上message用user的以太坊私鑰做簽章，以下爲送至IoT的打包内容(2)

#### IOT side implementation flow:
* IoT環境與user的環境差不多
* 當收到 user’s authentication package後，IoT開始進行驗證步驟，當verification step成功在繼續下一個step，否則drop掉以節省IoT算力
* Step
* Is the authentication package and message in the correct format as shown in equations 1 and 2 ?
* Is the message signature valid ? This is checked using the public key in equation 2
* Is the public key in the authentication package 2 similar to the one in the message 1 ?
* Is the token in message 1 similar to the token from the smart contract ?
* Is the source ip in message 1 similar to the source ip of the authentication package sender ?
* By hashing the public key in message 1 and taking the last 40 bytes .. Is the result similar to the Ethereum address from the smart contract ?

* 時間複雜


## 5 Testing and Evaluation
Note that generally, only “setter” functions will cost the user since they require miners to modify the blockchain where the “getter” functions don’t cost any time or money.
### Costs
* 一個transaction消耗2gwei，相當於21k GAS = $0.01
* 這個價錢是可以接受的，因爲它提供防篡改與分散式系統

* execution cost智能合約執行的成本
* transaction cost交易成本

### Testing
分成2各部分，手動測試與靜態分析
* 手動測試確保 robustness, security and performance.除理想的測試用例外，手動測試還包括惡意方案
* 靜態分析：靜態分析工具用於執行智能合約的自動安全評估。
#### Manual testing
* 送出login的交易到完成只要4秒
* 使用以下幾個惡意攻擊去測試IOT authentication script
– A replay attack failed since the attacker’s source IP needs to be identical to
the source IP in the signed authentication message.
– Modifying the signed authentication message failed since the script verifies
the message signature.
– Injecting the attacker’s own authentication package failed since the public
key should lead to the Ethereum address of the legitimate user.
– A man-in-middle may be able to sniff outgoing authentication packages. However, integrity is protected since he/she cannot modify the signed authentication message.中間人可能能夠嗅探傳出的身份驗證包。 但是，完整性受到保護，因為他/她無法修改簽名的身份驗證消息。

* 只要user keypair不要透露，就能確保這個方法的安全。
* 當一次驗證過後，access token就要被取代以確保安全

* 透過私有鏈與Ropsten公開測試網路各實驗一次
#### Automated testing: Static Security Analysis
* 以mythril工具做靜態分析
* It can operate in both whitebox驗證，回傳no issues
* 透過whitebox驗證，回傳no issues
* a control flow graph is created for the smart contract source code to assure all possible paths are checked. The graph is created using Ethereum Laser Symbolic Virtual Machine.
#### Evaluation

* **Availability** is described as removing the bottleneck and functioning without a single point of failure
* **Scalability** is usedhere to explain the added overhead to the usage of the application when more devices are added.
* **Decentralization** is the ability for the authentication application to run without depending on a central entity that may break the system if taken down
* **Tamper proof** is the assurance that saved data and transactions cannot be tampered once registered in the logs of the system.

## 6 Conclusion
* 本文討論了IoT授權的現有技術的優缺點，並提出了通過blockchain結合認證機制的新穎解法。
* blockchain的解法相較於現有的解法可以增加不可篡改行，去中心化特性
* solution有被設計與實作出來表示其解法是簡單且可行的
* 成功的授權合法的user存取IoT device

### Future work
* “Self Profiting Smart Contracts”
* . The user can provide access to the resources of his/her IOT device for a specified charge/使用者可以自己提供其IoT資源來賺取eth
* For example, a user can rent his/her camera to share stream with customers from all over the globe for a certain charge. This revenue can be used to pay for charges needed when using smart contract to login

## 參考文獻
* [OAuth 2.0 – Why It’s Vital to IoT Security](https://nordicapis.com/why-oauth-2-0-is-vital-to-iot-security/)
###### tags: `paper`