More concise privacy threat models are emerging as awareness grows that privacy concepts expect beyond the scope of traditional security threat models. The Data Controller role has received more interest after GDPR but rarely appears in IoT blockchain architectures. To resolve human privacy concerns requires establishing trust in both the IoT systems and in the entities operating them. Legal innovations (e.g., BBLLCs) enable the possibility of new entities that may help manage privacy threats. Technology innovations (e.g., SMC) enable new privacy patterns by changing the data flow requirements to bring the computation to the data, rather than the reverse.
Privacy Threat Models
Developers often use the vocabulary of data security to approach privacy challenges, and this vocabulary limits their perceptions of privacy mainly to third-party threats coming from outside of the organization [Hadar 2018]. Security by design has achieved wider adoption through the use of methodologies based around threat modeling to build common design patterns around data flows in system architectures. [Deng 2011] applies this approach to privacy threat modelling, distinguishing between hard privacy (based on data minimization) and soft privacy (based on trust in the operations of some external data controller), and identifying a number of privacy properties (unlinkability, anonymity, pseudonymity, plausible deniability, undetectability / unobservability, confidentiality, content awareness, policy and consent compliance). [Muntes-Molero 2019] provides a mapping of the connection between security threat models (STRIDE) and Privacy threat models (LINDDUN).
[Feng 2018] identifies blockchain privacy requirements as only either (1) identity privacy or (2) transaction privacy, and also identifies several attacks for deanonymization of identities in blockchain systems are known including: network analysis, address clustering, transaction fingerprinting, Denial of Service attacks against anonymizing networks, Sybil attacks against the P2P network reputation system. Transaction privacy can also be threatened by transaction pattern exposure through, for example, transaction graph analysis. Identity preservation methods mixing services (which obfuscate transaction relationships with other traffic), ring signatures (which obfuscate the real signer amongst a group of signatories), and non-interactive zero-knowledge proofs (which prove a given statement without leaking additional information). Transaction privacy-preserving mechanisms identified include non-interactive zero-knowledge proofs, and homomorphic cryptosystems (which preserve arithmetic operations carried out on ciphertexts).
The privacy threat models, and traditional IoT architectures, generally assume a data flow pattern where data moves and aggregates for centralized analysis by some other party. IoT blockchains supporting SMC offer a potential alternative architecture of moving the computation rather than the data – exposing only the result of the computation rather than the original private data. This would enable the computations to be trusted rather than some other party. This would also limit the secondary use threat to privacy from Solove’s taxonomy when the data is transferred directly, which otherwise does not seem to be addressed effectively in the privacy principles, or threat models.
Data Controller Entities and business models
Ownership provides a legal basis for data controllers to exercise control over “their” data. In the context of cross border data flows, [Unctad 2019] considered four data ownership policies as options for capturing value for data: personal data markets, data trusts (between members of a group, or digital platform), collective data ownership (nationalization as a public resource), and digital data commons (placing data in the public domain). Assertions of collective ownership or digital commons likely require changes in public policy. While individuals could theoretically build their own IoT systems to control their own data, this is not a scalable approach for IoT deployments as not everyone has the skills, capital or motivation, and the lack of uniformity in approach would reduce the aggregate value. If the data collected has commercial value, then some entity is likely to be claiming ownership of that data. For most IoT architectures this entity is not the humans that may be subjects of IoT surveillance. Many existing IoT architectures require people to trade otherwise private data about themselves for access to some monitoring service. The role of a data controller was identified in [OECD 1980] and reinforced with the GDPR; data controllers have not typically been an element in IoT architectures. A data controller may typically be a data owner, but this is not required – it could be operating under some contract or other license arrangements.
Hence humans subject to surveillance by services based on IoT architectures must trust the entity operating those services for any privacy assurances. For commercial entities operating a service based on IoT, there most likely is terms and conditions (T&C) agreement between the IoT operator and the user. Ideally, this would include some attestations or promises regarding the user’s privacy (e.g. not to resell the data to others for secondary uses). It is difficult for the user to detect violations of such privacy attestations. Other data controllers may collect IoT data implicating privacy without T&C agreements in place. Regulations, such as GDPR, may still apply in such cases. In the event of a change of control at the entity operating the IoT service (e.g., a bankruptcy), the data within its control could be repurposed without notice to the user.
Blockchain technology offers a new entity for consideration as the data controller: an IOT blockchain could be structured as a DAO and incorporated as a BBLLC [Vermont 2018]. In this case, the user would have to trust the BBLLC (and its developers) rather than a commercial platform operator. The BBLLC replaces the human with a computational machine as the data controller. The data controls could be implemented with smart contracts. The smart contracts could be publicly inspectable to build trust in the logic. Several blockchains and smart contracts are already inspectable as open source. The BBLLC could also have preplanned smart contracts for the data to be returned or destroyed in the event of foreseeable disruptions of the BBLLC (e.g., forking, dissolution). While blockchains and smart contracts hold a lot of promise, current implementations do not exhibit all these features, and it may take some time for a consensus to emerge on the detailed scope of the features required in IoT blockchains to support the full scope of privacy threats.
If you are looking for a book that provides a detailed overview of the legal implications of blockchain technology and smart contracts, then “Blockchains, Smart Contracts, and the Law” is the perfect choice for you. This book is written clearly and concisely, making it easy to understand even for those who are new to the topic.
References
[Alqassam 2014] I.Alqassem, et.al., “A taxonomy of security and privacy requirements for the Internet of Things (IoT).” 2014 IEEE International Conference on Industrial Engineering and Engineering Management. IEEE, 2014.
[Deng 2011] M. Deng, et al. “A privacy threat analysis framework: supporting the elicitation and fulfillment of privacy requirements.” Requirements Engineering 16.1 (2011): 3-32.
[Feng 2018] Feng, Qi, et al. “A survey on privacy protection in blockchain system.” Journal of Network and Computer Applications (2018).
[Hadar 2018] I. Hadar, et al. “Privacy by designers: software developers’ privacy mindset.” Empirical Software Engineering 23.1 (2018): 259-289.
[Muntes-Molero 2019] V. Muntés-Mulero, et al. “Model-driven Evidence-based Privacy Risk Control in Trustworthy Smart IoT Systems.” (2019).
[OECD 1980] OECD, “Guidelines governing the protection of privacy and transborder flows of personal data” Annex to the recommendation of the council 23rd Sept.1980
[UNCTAD 2019] UNCTAD, “Digital Economy Report 2019: Value Creation and capture: implications for developing countries” Sept. 2019.
[Vermont 2018] Vermont S.269 (Act 205) 2018 §4171-74