Systems of Systems with Security

In this report we present two case studies with Systems of Systems modelling. One model illustrates how Cryptographic parameter consistency can be checked using VDMPP for a System of Systems uses encryption to enforce Digital Right Management. The other model shows how a new formalism (CML) tailored specifically to Systems of Systems can express Multi-Party Computation protocol. The idea of using Canetti simulation proofs from Multi-Party computation as a model for refinement of models in CML is presented. Our goal is modest. We do not aim at proving security through refinement but to assists modellers/developers in maintaining security properties during refinement of a concept to designs

Regulation by Software

Software is neither law nor architecture. It is its own modality of regulation. This Note builds on Larry Lessig’s famous formulation that “code is law” to argue that Lessig was wrong to equate computer software with physical architecture. Although software resembles both law and architecture in its power to constrain behavior, it has features that distinguish it from both. The Note identifies four relevant attributes of software: It is ruleish, potentially nontransparent, impossible to ignore, and vulnerable to sudden failure. By assessing the impact of these characteristics in a given context, one can decide whether software is a good or a bad choice to solve a regulatory problem. Part I situates software within Lessig’s theory of different and complementary modalities of regulation that constrain individuals. In Code, he postulates four such modalities: law, social norms, markets, and physical architecture. He then argues that software is a subspecies of physical architecture as a modality. I argue instead that three basic characteristics of software establish it as a distinct modality that should not be conflated with any of the others: First, software is automated. Once set in motion by a programmer, a computer program makes its determinations mechanically, without further human intervention. Second, software is immediate. Rather than relying on sanctions imposed after the fact to enforce its rules, it simply prevents the forbidden behavior from occurring. Third, software is plastic. Programmers can implement almost any system they can imagine and describe precisely. Software is like physical architecture and unlike law in being automated and immediate. However, plasticity is more characteristic of legal systems than of architectural ones. Software’s plasticity interacts with its automation and its immediacy to produce consequences that set it apart from both law and physical architecture. In Part II, I turn to these distinctive consequences. There are four recurring and predictable patterns present in any regulation by software: First, along the traditional continuum between rules and standards, software lies at the extreme rule-bound end. Second, software can regulate without transparency. Frequently, those regulated by software may have no reasonable way to determine the overall shape of the line between prohibited and permitted behavior. Third, software rules cannot be ignored. Parties facing a decision made by software can, at best, take steps to undo what software has wrought. Fourth, software is more fragile than other systems of regulation. Hackers can turn its plasticity against it, and its automated operation means that unintended consequences are shielded from human review. Part III applies this analysis to two case studies. It predicts that software is a good way to manage negotiations and transactions in online marketplaces such as online auction sites and electronic stock exchanges. On the other hand, it predicts several pitfalls for the use of software to restrict the distribution of digital media