Partitioning a Digital Architecture

--- robots: noindex, nofollow --- # Heterogenity: A Security Design Pattern Any architecture requires the building blocks of design patterns. A house isn't built from scratch as revealed by Christopher Alexander in his book, _A Pattern Language_ (1977). Instead it's made up of repeatable patterns such as "a place to wait", "a sitting circle", and "open stairs". Technical systems are similarly made up of design patterns: the [architectures](https://developer.blockchaincommons.com/architecture/) espoused by Blockchain Commons are full of them. One such design pattern that has influenced many of our overarching designs is _heterogenity_. It's a security pattern that says: _**security is improved when things are different from each other**_. It might also be called _partioning_. It encompasses both _variety_ (when things very because they're different) and _separation_ (when things vary because they're apart). This pattern has been used across a wide number of architectural designs from Blockchain Commons, but they all go back to that central idea. [issues with variety: failure, how many M of N do you need?] [what is real variety?] ## Authentication Variety > **Problems:** > > * Singular authentication methods are hackable. > * Singular authentication methods are loseable. > * Traditional authentication methods are weak. > > **Solution:** > > * Require two or more successful methods for authentication. > > **Related Patterns:** > > * Key Separation, Threshold Access > > **Examplary Uses:** > > * Two-Factor Authentication (2FA) > * Collaborative Seed Recovery (CSR) Authentication Variety is a widely used example of the Heterogenity security design pattern. Two-factor authentication (or 2FA) offers an example: a user is asked to authenticate their identity through two separate means, most often a password and ownership of a device (such as a phone that receives a message or a device that runs Google Authenticator or another 2FA program), but sometimes through a password and a biometric measure (such as a fingerprint or facial recognition). In the Gordian architecture, Authentication Variety is suggested as a best practice for [Collaborative Seed Recovery](https://developer.blockchaincommons.com/csr/) and our reference app [Gordian Depo](https://github.com/BlockchainCommons/bc-depo-rust). Our main purpose for CSR servers is to allow the storage of individual shares of a seed separated by [SSKR](https://developer.blockchaincommons.com/sskr/). A user will then have to query two or more CSR servers to reconstruct their seed. Our best practice suggests that each service should have a different authentication method. One might accept a password, another might respond to an email address, another might require an update of a web site, another might require a face-to-face meeting. Each additional authentication test, using a different method, increasing the odds that the authentication is correct. ### Authentication Variety Advantages Authentication Variety mainly serves to improve the resilience and protection of whatever service or asset is accessed through the authentication. Specific adventages include: **No Single Point of Compromise.** If at least two separate authentication methods are required, then security is increased. And, it's probably increased by more than a factor of two, because an attacker now has to corrupt two different authentication methods _and_ correlate them. **Lower Threshold Possibilities.** Allowing multiple authentication methods offers the possibility of also incorporating *Threshold Access*, where multiple methods of access are supported and multiple methods of access are required, but where the numbers of access methods required _might_ be lower than the number of methods acquired. For example, in a typical CSR scenario, a user will have three shares protected by three separate authentication methods, but only require two of them to reconstruct their seed. If a lower threshold is used, that also removes Single Points of Failure (where an authentication method was lost) or Single Points of Denial (where access to an authentication method was blocked) [more?] ### Authentication Variety Disdvantages **Loss without Thresholds.** Authentication Variety might be dangerous if it's used without a Threshold Access pattern. Now, each new type of Authentication dramatically increases the security of your asset or service, but it also increases the likelihood of loss, because the loss of any authentication can cause total loss of access. Since the addition of authentication methods increases security exponentially, it can still be worthwhile provided the increased possibility of loss is not also exponential. If authentication methods are carefully built on systems that a user is unlikely to lose access to, such as their fingerprint, their faceprint, or their physical self, then an Authentication Variety system can still be safely constructed (but beware issues of inheritance!). [more?] More Patterns: [Quorum] [Different sorts of Authorization: Authentication/Authorization, but even just Authorization: differences in what you're asking for and what you're getting it] [1. Multiple Levels of Authenticator/Authorization] [different paths required for multiauth, not everything through email] [email that just warns you] [requirement of verification in email] [HIGHER level for reconstruction/restoration]][that's quorum] ## Key Separation > **Problems:** > > * Authentication & Signing keys can have different security profiles. > * Different devices have different security profiles. > * If one key is used for everything, its loss can be catastrophic. > > **Solution:** > > * Use separate keys for authentication & signing. > * Use separate keys on different devices > > **Related Patterns:** > > * Authentication Variety, Multisig > > **Examplary Uses:** > > * GitHub support of signing & authentication keys Key separation reveals how the Heterogenity pattern can be used for key management. It's a best practice that simply says: * Use different keys for different purposes. * Use different keys on different devices. We demonstrated this in our recent [Gordian Server v1.1.0 release](https://github.com/BlockchainCommons/GordianServer-macOS/releases/tag/v1.1.0) in which Shannon and I both signed with SSH keys that were designated for signing and keyed to the individual machines that we signed from. ### Key Separation Advantages **Protection of Sensitive Keys.** Some keys, such as signing keys, are more sensitive than other keys, such as authentication keys. Separating out their functionality means that more sensitive keys aren't exposed when they don't to be. **Reduced Cost of Recovery.** When a key does all functions on all machines, recovering from a loss or theft can be catastrophic. There may be no trusted way to rotate in a new key and there may no way to user services or access assets until that occurs. Meanwhile, an adversary may be making use of a previous key without you able to give any sort of warning. **Fewer Single Points of Failure.** In a worst case, loss of a all-purpose key could cause total loss of assets or services. Having multiple keys on multiple devices that do the same thing can implicitly give you protection from that, even if that wasn't the original goal. [more?] ### Key Separation Disadvantages **Increased Single Points of Compromise.** On the other hand, having keys on multiple devices that all do the same thing means that the loss of any of those devices results in a compromise. Even though the recovery might be easier afterward, there's still a period of vulnerability. **Return of the Bag of Keys.** This methodology implicitly creates a huge bag of keys, an old old problem for PKI systems. Users will have to figure out ways to manage them reasonably, especially if there's a desire to backup keys from multiple servers. **Required Server Support.** To be able to truly support the Key Separation pattern requires support from the PKI or from other services that either use or manage the keys. Ideally, they need be able to label uses and locations of keys with metadata, to help users in their management. [more?] -- [FOLLOWING NEEDS TO BE REWRITTEN FOR NEW STYLE] ## Functional Seperation In order to partition services, you examine a digital application and identify individual sub-services that can be meaningfully and usefully separated. This should result in sub-services that each offer a single function or a closely aligned group of functions. Good reasons for partitioning services include: * One service holds secrets that other sub-services don't need to know. * One service holds personal information that other sub-services don't need to know. * One service has open connections to other internet services. * The functions of a service are open to competitive innovation. In the case of the Gordian Architecture, secrets (seeds) are held on [Gordian Seed Tool](https://github.com/BlockchainCommons/GordianSeedTool-iOS), while open connections to other Bitcoin machines occur in [Gordian Coordinator](https://github.com/BlockchainCommons/iOS-GordianCoordinator). Similarly, [Spotbit](https://github.com/BlockchainCommons/spotbit) may manage open connections ot a variety of different clients each requiring its services. Thus, each service is partitioned. ### The Advantages of Functional Heterogenity Service partition improves the resilience and overall quality of an architecture in several ways: * **Limited Honeypots.** Because secrets and personal information are purposefully partitioned, there are fewer data honeypots. This makes each individual service a smaller target and also limits the damage if a service is breached. * **Tighter Code.** Because each service is focused on a more precise and specific functionality, code is likely to be tighter and less prone to the errors that can sneak into larger codebases. * **Coopetition.** Because functionality is partitioned, different entities can each offer their own take on a service, creating competition within the ecosystem, which can also improve innovation. * **Future-proofed Openness.** Because of the possibility of coopetition, individual services are encouraged to adopt interoperability specifications such as [Uniform Resources](https://www.blockchaincommons.com/specifications/Blockchain-Commons-URs-Support-Airgapped-PSBTs/). This improves the openness of the system, and also introduces future-proofing: even if current services disappear, data can be recovered with future services due to the open specifications. [i need to figure out if there's meaningful difference between function/service in this new/updated article] ## Service Heterogenity Service partitioning is just the first step in functional partition. An additional advantage to this architectural pattern is that individual services can be protected by information gaps, which "widen" the distance between two different services. Blockchain Commons has identified two main types of information gaps: * **Air Gap.** A literal gap of air between two different services. Information is carried by removable storage, by QR code, or by typing it in by hand. * **[Tor Gap](https://github.com/BlockchainCommons/torgap).** A connection between two services that occurs via Tor, which helps to ensure mutual anonymity. [Gordian Seed Tool](https://github.com/BlockchainCommons/GordianSeedTool-iOS) is an example of an app in the exemplar Gordian architecture that uses airgaps: seeds can be read into GST (or stored) using QR codes or NFC tags; PSBTs can similarly be read or written using these means. [Spotbit](https://github.com/BlockchainCommons/spotbit) is an example of a service that uses TorGaps. Individual clients can talk to Spotbit across Tor, thus not revealing that they're seeking Bitcoin pricing services and not revealing to the Spotbit server who they actually are. ### Service Separation Adding service separation to service partition can offer additional advantages to an architecture. Some of the advantages of Airgaps include: [following are maybe notes] [limited interactivity] [attack slowdown] [protectected information] Some of the advantages of Torgaps include: [protected lookups] [limited information] Article to respond to criticisms of airgap technology addressed in recent multisig-scenario PR #15, gordian & smart custody practices of functional seperatation/partitioning (such as https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/Practices.md#separate-seeds--keys), etc.) and separate ecosystem roles. Other related articles: https://shiftcrypto.ch/blog/does-airgap-make-bitcoin-hardware-wallets-more-secure/ https://www.computer.org/publications/tech-news/trends/qr-code-risks https://www.techradar.com/features/do-not-overlook-the-security-risk-posed-by-qr-codes Related minor task. Decide on our language here (separation? partitioning? segregation) and make consistent in SmartCustody and Gordian repos. -- We definitely disagree on that. I think there's room for considered and fair argument on how great the security improvement is, but I'm pretty sure something is there. I think the buffer flow bug is a fine example: yes, a QR code can still buffer-overflow a badly written hardware wallet, but without an interactive possibility for back-and-forth the damage is much more limited and much harder to take advantage of. Take the example of the classic buffer overflow, when the Morris Worm attacked fingerd. Basically, a buffer overflow allowed the creation of a new worm on the remote machine. If that occurred in an airgapped situation, the user would then have to agree to let his device talk to another fingerd (basically, a connection he didn't request) and then he'd have to OK the sending of a worm-QR (which would require the info-reporting software on both sides of the gap to be compromised). That's very different from a situation where communications can occur without user OK on both sides. And, even if an export were successful, the speed of the attack would be so slow that it would be detected before major damage was done, at least for the overall ecosystem. -- Agreed. But QR doesn't have a monopoly on limiting interactivity. Similarly to the above, a connected usb plug can also build in this kind of speed limitation. I notice you say "QR" and we say "airgap", so that's probably one good point to mention. Otherwise, you say other methods could introduce these limitations, and we say airgap requires it. So that's probably another. Going to introduce some additional clarity on that, thanks! -- # Partitioning a Digital Architecture The concept of **functional partition** is key precept of the [Gordian Architecture](https://github.com/BlockchainCommons/Gordian/blob/master/Docs/Overview-Architecture.md). This means that rather than grouping multiple services into singular applications, those services should instead be split apart along functional lines, with that split then strengthed by a variety of means. **Functional partition** is thus built on two core precepts: * **Service partition.** Individual functions are partitioned in discrete services. * **Service separation.** Individual services are separated from each other. There are strong arguments for each of these precepts.