464
`
`DISTRIBUTED SYSTEMS FOR SYSTEM ARCHITECTS
`
`users modify them? Is the access control mechanism itself protected or done
`by the general operating system functions?
`The reference monitor addresses these questions, with the aim of formally
`ensuring protection. Originally proposed in (Lampson, 1974), many works
`have been based on it, broadening the scope of the original definition. In the
`rest of this part we will use the notion of reference monitor. To help us with
`our explanations, let us identify a few useful properties of a generic reference
`monitor (RM), exemplified in Figure 18.16:
`
`Completeness -
`
`the RM is invoked for any access to any object;
`
`Obligation -
`
`the RM refers to an access control rule set;
`
`Self-protection -
`
`the RM is immune to intrusion.
`
`The completeness property is secured if the RM stands between all subjects
`and all objects. The obligation property is compatible with mandatory access
`control policies. One may of course implement an RM that does not exhibit
`the obligation property, following a discretionary policy5. The self-protection
`property is secured if the RM resides on a trusted computer base (TCB). As
`we discussed in Section 18.3, in certain applications one may implement an
`RM over an imperfect TCB and in that sense partially fulfill the self-protection
`property.
`
`Figure 18.16.
`
`The Reference Monitor Model
`
`18.8 ARCHITECTURAL PROTECTION: TOPOLOGY AND
`FIREWALLS
`
`The way the architecture of the network is laid down helps implementing protec(cid:173)
`tion, and forms part of what we might call passive security measures. Devices
`like hubs, bridges and routers provide basic yet effective protection. Firewalls
`implement more sophisticated forms of architectural protection, both at phys(cid:173)
`ical and logical levels.
`
`5The original work on the RM model did not follow a mandatory policy.
`
`Exhibit 2026 Page 478
`
`

`

`MODELS OF DISTRIBUTED SECURE COMPUTING
`
`465
`
`18.8.1 Topology
`
`A naive form of internal network architecture is exemplified in Figure 18.17a.
`This flat approach has the consequence of exposing the whole infrastructure to
`an intruder that penetrates past the organization's entry router.
`
`Figure 18.17.
`
`Network Architecture: (a) Flat
`
`Figure 18.17b exemplifies the subnetting approach, that is, division of a net(cid:173)
`work in two or more subnets, each with its own addressing mask, such that
`traffic is diverted right at the entry router to the appropriate subnet. This is
`valid both for traffic coming into the organization, and for traffic between differ(cid:173)
`ent subnets of the organization. This division should be made according to an
`appropriate risk analysis: in the figure, the notion of a more exposed laboratory
`environment (Internal Network 2) versus the rest of the system (Internal Net(cid:173)
`work 1) is patent. This is a primary form of error containment: intrusion in one
`subnet does not imply the immediate intrusion in the whole system. Subnet(cid:173)
`ting also provides a convenient way for primary countermeasures:
`traffic may
`be easily blocked to/from specific networks, without affecting the operation of
`the whole organization.
`
`Laboratory
`
`Figure 18.17 (continued).
`
`Network Architecture: (b) Subnets
`
`The scenario depicted in Figure 18.17c exemplifies the utility of another
`device: the bridge. By placing the department services and the system admin(cid:173)
`istrator workstations in the Critical Network past the bridge, we neutralized
`
`Exhibit 2026 Page 479
`
`

`

`466
`
`DISTRIBUTED SYSTEMS FOR SYSTEM ARCHITECTS
`
`sniffing attacks coming from Internal Network 1. Last but not least, struc(cid:173)
`tured cabling, such as hub-based Ethernet, eases reconfiguration and primary
`countermeasures. Switched Ethernet further renders sniffing ineffective, since
`it restricts the broadcasting ability of the medium.
`
`Dept.
`Server
`
`Figure 18.17 (continued).
`
`Network Architecture: (c) Bridges
`
`18.8.2 Firewall Architecture
`
`A basic firewall is like having a "doorman" at the (single) entrance of a facility:
`it allows or forbids information in and out, according to some criteria. More
`specifically, a firewall is a set of components placed between an external network
`and an internal network, with the following properties:
`• all incoming and outgoing traffic must go through the firewall
`• only authorized traffic must be able to get through
`•
`the firewall hosts are trusted computing bases (TCBs)
`
`Figure 18.18.
`
`Single-level Firewall Architecture
`
`The business of a firewall system designer is to approximate these properties,
`by putting the adequate firewall junctions and architecture in place. Firewall
`architectures are built around routers, subnets and bastions, the trusted hosts
`that run firewall functions. These architectures take essentially two forrfi'S. The
`simplest, and most common, is a single-level firewall architecture, also known
`
`Exhibit 2026 Page 480
`
`

`

`MODELS OF DISTRIBUTED SECURE COMPUTING
`
`467
`
`as screened-host firewall, as depicted in Figure 18.18. The firewall comprises
`a router and a bastion, a combination also known as a dual-homed host, that
`stands between the external network (e.g., Internet) and the organization's (in(cid:173)
`ternal) network, such that all traffic is inspected by the bastion. In a variation
`of this architecture, the bastion stands single-homed in the internal network,
`but all outgoing and incoming traffic goes through the bastion (e.g., Internet -t
`router -t bastion --t internal host, and vice-versa). This architecture places all
`hosts in the internal network at the same level of threat. The problem is that
`any current organization is bound to have services that should operate under
`different exposure scenarios.
`
`Server
`
`Inner
`Firewall
`.~
`
`~S S !f~"""-------tIO
`.
`
`=+:~~rna,ie~ork
`
`Outer
`Firewall
`
`~;~:: Sfl s~
`
`(PFS)De.milit~~
`
`Figure 18.19.
`
`Two-level Firewall Architecture
`
`Figure 18.19 presents the most used partial fix to that problem, a two-level
`firewall architecture, also known as screened-subnet firewall. The outermost
`firewall is normally also the outside router of the organization's network, and
`normally performs simple filtering functions. The inner firewall, a dual-homed
`host, performs more elaborate functions, such as representing internal protocols
`or applications. Between the inner and outer firewalls lies a subnet called the
`de-militarized zone (DMZ). The DMZ is the place to locate hosts necessarily
`subjected to high levels of threat, such as anonymous public front-ends, e.g., to
`Web page, directory or commerce services. The reason for placing these servers
`in the DMZ instead of just letting them be freely accessible from the Internet is
`that they can still enjoy some protection from the firewall system. Besides, the
`outer firewall is also a useful device for countermeasures: it can be instructed
`in real-time by the inner firewall to disable certain flows considered suspicious,
`that attack either the inner network hosts, or the DMZ hosts. In a variation
`of this architecture, the bastion stands in the DMZ, with all traffic between
`external and internal networks going through it. Several of these bastions may
`exist in a DMZ, processing different flows and services.
`Firewall functions are the logical complement to the physical separation
`achieved by the architecture. They are divided into two main groups, that we
`study next:
`
`filters - the traffic flow passes through the firewall to end services in the
`internal network, its content being inspected by filters on a go-no-go
`basis
`
`Exhibit 2026 Page 481
`
`

`

`468
`
`DISTRIBUTED SYSTEMS FOR SYSTEM ARCHITECTS
`
`the traffic flow ends or starts in the firewall, being intercepted
`proxies -
`and processed by representatives of end services in the internal net(cid:173)
`work
`Table 18.2 illustrates the main differences between the two. Filters work by
`inspection of packet data that goes through the firewall, and as such they are
`essentially stateless. Working at communications packet level, the filtering pro(cid:173)
`cess is necessarily semantically limited (addresses, ports, interfaces). Rules are
`content oriented, such as Udeny packets containing source address X". Proxies
`intercept calls to the genuine servers, blocking direct communication through
`the firewall, and act as representatives of those servers. As such, they are
`stateful, dealing as much with data as with state, since they must handle the
`progression of service requests such as "connect to FTP server". More than
`packets, they reason in terms of protocols, users, and services, which provides
`room for richer and thus more accurate protection semantics. Rules are both
`content and action oriented, such as "allow user X to access service Y". Since
`nothing comes for free, proxy systems are normally less efficient than packet
`filter systems.
`Certain firewalls implement a variant of PFS, called stateful packet filter
`(SPF). Filters, although acting right above layer 3, probe further into each
`packet looking for known high-level protocol headers. SPFs are a form of dy(cid:173)
`namic packet filters, in that they adapt the rules to a flow of packets. Firewall-1
`(see Section 19.2) is one example. On the other hand, a variant of proxy exists
`called adaptive proxy, where the proxy is capable of interpreting varying degrees
`of threat for different instances of a same service. Gauntlet (see Section 19.2)
`is one example.
`
`Table 18.2.
`
`Comparison between Firewall Functions
`
`Filters
`
`Proxies
`
`inspection
`stateless
`data based
`poor semantics
`packet level
`content oriented rules
`faster
`
`interception
`stateful
`data+state based
`rich semantics
`protocol/user/ service level
`action oriented rules
`slower
`
`18.8.3 Packet Filter Systems
`
`The principle of packet filtering systems (PFS) is shown in Figure 18.20a. The
`filtering mechanism is defined by the following:
`
`•
`
`there is a list of rules to allow or deny packets through the filter in either
`direction;
`
`Exhibit 2026 Page 482
`
`

`

`MODELS OF DISTRIBUTED SECURE COMPUTING
`
`469
`
`• each list element is a tuple (action, origin, destination, type, direction, subnet) ,
`where: action is either allow or deny; origin is a complete source I d, for
`example TCP /IP address/port, or subnet address/mask; destination is the
`same, for a destination I d; type when available is the type of packet, which of(cid:173)
`ten corresponds to a given protocol; direction is one of inbound or outbound;
`interface represents the subnet from/to which the packet comes/goes, through
`one of the interfaces to which the firewall is directly connected;
`
`•
`
`•
`
`the headers of all incoming and outgoing packets are scrutinized against the
`contents of the list.
`
`the rules are applied in order; a packet is accepted immediately an "allow"
`rule becomes true, or rejected if a "deny" rule becomes true;
`
`Protocol Proxy (e.g. FTP)
`
`:~9~V:s~:
`:~:;:::::::
`~ :'~~ ~ .:
`' : : ..:
`.
`
`Network
`fr?tocol
`(~.g~TCPIIP)
`
`:PROXyri,j:
`::'::::' )~:
`
`NetwOrk
`Proto~o~
`(e.g.TCr'~
`
`[1·..· ~
`Internal Network
`
`~etwork
`Protocol
`(e.g.TCPIIP)
`
`Netwqrk
`Protodol
`(e.g.TCPIIP)
`
`lO-
`
`.
`
`I
`.
`.
`I .
`•
`r-ilr--S: B----~
`
`External Network
`
`Internal Network
`
`Figure 18.20.
`
`Types of Firewall functions: (a) Packet Filter, (b) Proxy
`
`The PFS can be used for actions such as: blocking all packets coming from
`a suspicious host; disallowing telnet connections from the outside; enumerating
`the hosts allowed to access a given service. An example rule could be (deny
`from any to 194.117.21.00 typeTelnet inbound ieO), meaning that telnet packets
`coming from any machine in the subnet behind interface ieO, and addressed
`to any machine of protected subnet 194.117.21.00, are blocked. A prudent
`security policy can be implemented by using allow statements to specifically
`permit the desired traffic flows and denying everything by default as the last
`rule. Conversely, a pe'rmissive security policy will be implemented by using
`deny to block undesired flows, and allowing everything by default in the end.
`Firewall-1 (see Section 19.2) is a widely known example of PFS.
`Network address translation (NAT) complements filtering to ensure logical
`separation.
`It consists of assigning invalid addresses to the internal network
`hosts, such that any traffic going in or out has to undergo a translation of the
`destination or source address, respectively, at the firewall router. This controls
`access of legitimate users to the external network, and hides the composition
`of the internal network to intruders.
`
`Exhibit 2026 Page 483
`
`

`

`470
`
`DISTRIBUTED SYSTEMS FOR SYSTEM ARCHITECTS
`
`18.8.4 Proxies
`
`this means they
`PFSs allow packet flows to internal hosts and are stateless:
`cannot prevent direct probing and penetration attacks to internal hosts, as
`long as each individual packet looks innocent. If instead of inspecting passing
`traffic, it were intercepted and re-originated from the firewall, the chances of an
`intruder would be reduced. Figure 18.20b introduces such a firewall function,
`the proxy. Proxies reside in the firewall, and are representatives of application
`or protocol services (or daemons in UNIX language). A proxy stands for a
`genuine protocol server- such as HTTP, FTP, Telnet, or SMTP- which is
`normally in the internal network. The user wishing to access such a service
`is connected to the proxy server instead (left of the figure). The proxy. client
`side performs the dialogue with the real server (right of the figure).
`Proxies
`relay all traffic back and forth between the user in the external network and the
`protocol server in the internal network. For that reason, proxies are also called
`circuit gateways. The proxy mechanism is defined by the following generic
`rules:
`
`•
`there is a list of rules to allow, restrict or deny access to services;
`• each element of the list is a service-specific tuple, that may comprise: user
`Id and origin; service and server; type of access control (e.g., ACM, ACL);
`type of authentication (e.g., password, signature); type of restrictions (e.g.,
`from IDS); event monitoring and audit trail required; etc.;
`requests arriving at the proxy are tested against the rules, and serviced if
`"allowed" or blocked if "denied";
`• state is maintained during service execution, to ensure it is carried on cor(cid:173)
`rectly.
`
`•
`
`Proxies significantly limit the freedom of action of an intruder in the internal
`network, and they are more precise than packet filters, since they act at a higher
`A proxy rule may be something like (allow anyuser
`level of abstraction.
`from domain cs.comell.edu to ftp to FTP.di.fc.ul.pt requiring authentication
`X509_certificate requiring authorization loca~. It means that any user coming
`from cs.comell.edu may attempt to log into the FTP server of di.fc.ul.pt, then
`pass an authentication process based on presenting a valid X.509 certificate,
`and then following the local ftp server ACL control.
`
`18.8.5 Application Gateways
`
`Application gateways are proxies working at a higher level of abstraction than
`circuit gateways. An application proxy server (a front-end of the application)
`is installed in the firewall, which for all purposes becomes the interface to the
`clients. The gateway, besides performing logging, validation and filtering func(cid:173)
`tions, forwards the client's request to the real application server in the internal
`network, and receives the replies back. The overall picture is represented in
`Figure 18.20c.
`
`Exhibit 2026 Page 484
`
`

`

`MODELS OF DISTRIBUTED SECURE COMPUTING
`
`471
`
`Application Gateway
`
`~
`
`~~~~~~~.;:
`
`'*
`
`(~~~.~~;~~)
`
`Split Gatew,.....-a"",,"-_--,
`"
`.
`...-
`ecurelP
`
`;
`
`~~.~~~.~~~~i;:
`
`:fi.?~~~~~;?
`
`C9mm's
`Protocols
`($.9. TCPIIP.
`t(TTP.Telnet)
`
`Ei.~:~) ~ ..
`
`fl-o-+'t--«fo<
`External Network
`
`Comni's
`Protocols
`(e.g. TCP,IIP.,
`HTIP,Telnet)
`~----"'"-'-'.,;;::.~
`\
`/
`i 4--flq..-,-",
`Internal Network
`
`Gomm's
`p:r9tocols
`(e.g. TCPIIP,
`H!ip,Telnet)
`
`(E~~4 m~~........,~!'O ~
`
`;
`
`:
`
`Comni'~
`Protoc~l~
`(e.g. TCP/IP;,
`HTTP,Telnet) ,
`~~--''i-"~A;;::)
`.........,..................•...
`
`SubnetA
`
`Su netS'
`
`Figure 18.20 (continued)
`Types of Firewall functions: (c) Application Gateway; (d) Split Gateway
`
`If all access from the outside is done through protocol and application gate(cid:173)
`ways, an internal network may be completely closed to the outside at the
`protocol level. An intruder's freedom of action is then reduced to trying to
`tamper with the gateway or with the firewall's O.S. In consequence, applica(cid:173)
`tion gateways are the most powerful and precise' protection devices in firewall
`architectures, because they exert control at the highest possible semantic level:
`that of the application itself. However, they are also the less versatile and most
`difficult to build. Whereas COTS packet filters and protocol proxies abound
`for the best known network environments and protocols, application gateways
`must normally be custom made, with very few exceptions. Gauntlet (see Sec(cid:173)
`tion 19.2) is a widely known example of proxy and application gateway system.
`Note that there is nothing that prevents combining filters and proxies in
`the same bastion, or distributing them by the components of a firewall.
`In
`two-level firewalls, a current configuration is as shown in Figure 18.19:
`the
`outer firewall performs packet filtering and routing; and the inner firewall hosts
`protocol and application proxies. As a concluding remark, keep in mind that
`the effectiveness of the firewall functions we have described is in the inverse
`proportion of their generality. It is up to the architect to select the configuration
`that best addresses the tradeoff between security and functionality, according
`to the security policy previously defined.
`
`18.8.6 Split Gateway Architectures
`
`Sophistication of Internet-based distributed computing models calls for mod(cid:173)
`ularity and splitting of functions, in support of multi-tiered client-server op(cid:173)
`eration. Today's applications are becoming significantly more complex and
`performance-demanding than is achievable by CGI-based connection of Web
`servers to application servers. These applications are using more powerful,
`stateful middleware based on the connection of front-end Web servers to back(cid:173)
`end application servers, through enabling technologies such as Object Request
`Brokers, Internet Inter-ORB protocols (IIOP), JDBC and ODBC database con-
`
`Exhibit 2026 Page 485
`
`

`

`472
`
`DISTRIBUTED SYSTEMS FOR SYSTEM ARCHITECTS
`
`nectors, Web Request Brokers and Event Brokers. These constructs must be
`secure, and it makes sense that they operate across firewall architectures, for
`example, by running the back-end server in the internal network and then, both
`the front-end and the middleware in a firewall, or alternatively, the front-end
`server in a DMZ and the middleware in a firewall bastion.
`To support the necessary modularity, address space separation, and location
`independence, we resort to what we may call a split gateway architecture,
`depicted in Figure 18.20d. It is an application gateway where the server-side
`and. the client-side modules are stateful machines that operate independently,
`and communicate through a generic IPC. Both intra-host and inter-host IPC
`operation are supported transparently, such that the split gateway may either
`live on two separate hosts, as depicted in the figure, or in two disjoint realms of
`a protected O.S. in a single host. These hosts must be considered as bastions
`in what concerns their configuration and operation.
`IPC must be secure, in
`either configuration.
`
`18.9 FORMAL SECURITY MODELS
`
`In this section, we discuss formal ways of specifying and assessing security of
`computer systems. Namely, we discuss how, in a multi-level security mode, we
`specify which subject security classes can access which object access classes,
`and with what rights (e.g., can a top-secret subject write to an unclassified
`object?). Secondly, we describe standard security classification and evaluation
`criteria for computer systems (e.g., how secure is computer system X?).
`
`18.9.1
`
`Security Policy Models
`
`It is obvious that for a verifiable goal to be attained, security policy rules
`must follow some formal specification. There exist several attempts to enforce
`mandatory access control policies in a formal way. The first such specification
`was the Bell-LaPadula model (Bell and LaPadula, 1973), which aimed at se(cid:173)
`curing confidentiality. Other models followed, such as the Biba model, inspired
`by the Bell-LaPadula but addressing integrity instead (Biba, 1977), and the
`Clark-Wilson model, more adequate for enterprise systems (Clark and Wilson,
`1987). Formal specification methods verifiable by model checking are discussed
`in (Ryan et aI., 2000). There is not a generally accepted model addressing all
`needs, and this is a current research topic.
`In generic terms, the relations between subjects and objects are established
`on the basis of their security classes and the need to know. We say s dominates
`o (or 0 is dominated by s) when the security class of s is at least as high as o's,
`and s needs to know o. We denote it as s 2:: o.
`
`Bell-LaPadula Model The Bell-LaPadula model, BeLa for short, describes
`the information flow in a system in terms of very primitive read/write oper(cid:173)
`ations.
`It aims at ensuring that the confidentiality property is respected in
`systems where data and computations of different security levels exist, and
`which can be accessed by subjects of different security classes. Consider sub-
`
`Exhibit 2026 Page 486
`
`

`

`MODELS OF DISTRIBUTED SECURE COMPUTING
`
`473
`
`ject s with security class C(s), and object 0, with security class C(o). The
`access rights granted to s on 0 can be read or write. The properties of the
`BeLa model are then:
`Simple Security Property - A subject s has read access to object 0
`only if C(s) ?: C(o)
`*-Property - A subject s has write access to object 0 only if C(s) ::;
`C(o)
`Observe that a subject cannot read data from a level higher than its security
`class, that is, read-up is not possible. More counter-intuitively, the answer to the
`question in the beginning of the section- can a top-secret subject write to an
`unclassified object?- is "no!": a subject cannot write data to a level lower than
`its security class, that is, write-down is prevented. Also, if it writes data, it may
`not be able read it back. This causes a certain difficulty in retrieving, using and
`updating information for a repository. In fact, practical programming with this
`model entails significant complexity. However, note that by preventing read(cid:173)
`up, confidentiality is protected in normal conditions. By making write-down
`impossible, information leakage attacks, directly or by means of Trojan horses,
`are blocked.
`In the Biba model, which is the converse of the BeLa model, the security
`class interpretation concerns the sensitivity with regard to integrity. The model
`properties, conversely to the BeLa model, forbid read-down and write-up, as a
`way of preserving integrity of information. While no write-up is intuitive, note
`that the reason why read-down is prevented is to avoid corruption of the system
`with untrusted (low-integrity level) information.
`
`18.9.2 Trusted Computer System Evaluation Criteria
`
`Evaluating and grading the security of computer systems through objective
`evaluation criteria is important, for it allows us to compare systems of different
`models and makes. The Trusted Computer System Evaluation Criteria (TC(cid:173)
`SEC), or Orange Book (TCSEC, 1985) originating from the U.S.A., and the
`Information Technology Security Evaluation Criteria (ITSEC) (ITSEC, 1991),
`from Europe, were initial efforts in that direction. More recently, the bodies
`involved in both converged in a global standard, called Common Criteria for
`Information Technology Security Evaluation (CC) (CC-ITSE, 1998), bound to
`become an International Standard (ISO 15408) at the time of this writing.
`The CC standard structures both the functionality requirements and the
`assurance requirements of a system i.e., what the product should do, and what
`trust can be placed in what it does. These requirements are expressed in terms
`of classes.
`The standard is highly modular, making possible a huge number of combi(cid:173)
`nations of classes of functionality and assurance requirements. However, it is
`expected that "typical" combinations emerge from the industry. The CC, like
`the preceding standards, provide several levels of trust. There are 7 Evalua(cid:173)
`tion Assurance Levels (EAL) that measure the user trust on a system (EAL7 is
`
`Exhibit 2026 Page 487
`
`

`

`474
`
`DISTRIBUTED SYSTEMS FOR SYSTEM ARCHITECTS
`
`Table 18.3.
`
`Common Criteria (CC)- Security Levels
`
`Levels
`
`Description
`
`TCSEC equiv. Classes
`
`EALI
`EAL2
`EAL3
`
`EAL4
`
`EAL5
`
`EAL6
`
`EAL7
`
`functionally tested
`
`structurally tested
`methodically tested
`and checked
`
`methodically designed,
`tested and reviewed
`semi-formally designed
`and tested
`semi-formally designed,
`verified and tested
`
`formally designed,
`verified and tested
`
`I D
`I
`-
`I Cl- Discretionary Security
`C2- Controlled Access
`
`Bl- Labeled Security
`
`B2- Structured
`
`B3- Security Domains
`
`Al- Verified Design
`
`highest). Evaluation Assurance Levels are represented in Table 18.3, which also
`provides a mapping to the well-known TCSEC security classes. EALI applies
`when minimal protection, namely of personal information, is desired, but secu(cid:173)
`rity is not a main concern. EAL2 and EAL3 are expected to have been tested
`against the functional criteria.
`In EAL4, it is expected that specific crucial
`subsets of the design have been methodically designed having security in mind,
`and that the whole has been thoroughly tested, and reviewed independently.
`Level EALI-EAL4 assurance can generally be retrofitted into existing products
`and sub-systems (such as O.S.s). Levels above EAL4 require adequate design
`from the start. They provide maximum assurance, by application of specialized
`security engineering techniques. They also become more complex and expen(cid:173)
`sive to implement. EAL5 would represent the top assurance still within the
`commercial systems area. EAL6 and EAL7 would apply to classified systems
`and military.
`
`18.10 SECURE COMMUNICATION AND DISTRIBUTED
`PROCESSING
`
`Secure channels and secure envelopes are basic paradigms of secure communi(cid:173)
`cation and the support for distributed processing models with security, such
`as remote sessions, RPC, and electronic mail. We study the above-mentioned
`models and mechanisms in this section.
`
`Exhibit 2026 Page 488
`
`

`

`MODELS OF DISTRIBUTED SECURE COMPUTING
`
`475
`
`18.10.1 Establishing Secure Channels
`
`Secure channels, that we studied in Section 17.11, are one of the basic support
`primitives for distributed processing. They underlie file transfers, remote ses(cid:173)
`sions, remote procedure calls, HTTP interactions, and so forth. They may be
`implemented in several ways. In what follows, we will make a general analysis of
`how to achieve each of the secure communication properties: authenticity, con(cid:173)
`fidentiality, integrity. For simplicity, and without loss of generality, we consider
`the case of point-to-point communication.
`
`Authenticity In order to achieve authenticity in a secure channel, the princi(cid:173)
`pals should authenticate themselves, in one of the styles shown in Figure 17.17.
`Mutual authentication desirably guarantees that both principals know whom
`they are talking to, mandatory if the channel is bi-directional. Several pro(cid:173)
`tocols are discussed in Section 18.5. If only symmetric cryptography is being
`used, shared-secret authentication protocols are the ones to be used. If asym(cid:173)
`metric cryptography is available, then one can take advantage from the power
`of signature-based authentication. Since the channel is being established for
`exchanging a possibly large number of messages, with desirably low latency, it
`is convenient to avoid having to do authentication on every future message ex(cid:173)
`changed. Some of the short-term key exchange protocols studied in Section 18.6
`are embedded with authentication, finishing by leaving the principals with a
`session key K ss , known both of them and no one else. By majority of reason,
`any future message exchanged that has a suitable cryptographic function of
`that key enjoys the authenticity property if: messages are always encrypted
`with K ss ; or messages are cryptographically checksummed with a function de(cid:173)
`pending on K ss (see MACs in Section 17.5, and Figure 17.8). Note that the
`validity of these two assumptions relies on subtle aspects: (a) that the recipient
`knows something about the partial content (e.g., headers) or about the struc(cid:173)
`ture of messages; (b) that forging or modifying the encrypted product, may
`not possibly yield something intelligible in terms of (a), after decryption; (c)
`as (b), for the cryptographic checksum and its verification.
`
`Confidentiality When confidentiality is desired,
`the communication must
`be encrypted. A channel using exclusively asymmetric cryptography for both
`authentication and encryption would be extremely simple and secure. How(cid:173)
`is very
`is not recommended for immediate communication, since it
`ever,
`it
`slow. Practical secure channels resort to two alternatives: purely symmetric
`cryptography; hybrid cryptography.
`In a symmetric system, after shared se(cid:173)
`cret authentication and key exchange have been performed, as we just saw,
`the channel has a session key. With hybrid cryptography, principals start with
`using their public/private key pairs to exchange, encrypted and/or signed, a
`session key as well (see the protocol described in Section 18.4.5). After that,
`in both approaches, they use that key for symmetric encryption/decryption.
`
`Exhibit 2026 Page 489
`
`

`

`476
`
`DISTRIBUTED SYSTEMS FOR SYSTEM ARCHITECTS
`
`Integrity In order to achieve integrity, messages must be cryptographically
`protected in a way that any modification whatsoever (accidental or intentional)
`is detected. This can be achieved in one of two ways: by a cryptographic
`checksum, such as suggested for authenticity (in this role, it is often called
`a message integrity check, or MIC); or by a digital signature. Note that the
`proviso that we made under Authenticity above, on the recipient having to know
`what it expects after decryption or verification, still applies here. Integrity can
`also be protected by encryption, but the method is not general, since it requires
`a modified message to decrypt to garbage, and this is not always achievable.
`
`18.10.2 Secure Tunnels
`
`The simplest form of building a secure channel through a network such as
`the Internet is shown in Figure 18.21a. Encrypted and/or integrity protected
`payload data blocks are encapsulated in protocol packets, Le., IP datagrams.
`This does not always work. Take networks A and C, interconnected by network
`B, and a problem: we want a packet to go from A to C, but for some reason
`it cannot circulate through B (e.g., B does not understand the protocol). The
`first approach will not work, so we have to use another form of secure channel.
`
`I,
`Data p
`I.. "'#$%43543'fga8a=?"'lf"'+Mfdg~S1'kji
`
`.1
`.J
`
`Headert
`
`Headerp
`
`Headert
`
`Headerp
`
`Headert
`
`I
`
`,:
`
`I
`
`(a)
`
`Datap
`
`.>Oatal
`(b)
`
`Datap
`
`Da·tat
`(c)
`
`Payload Data
`
`Encrypted
`Payload Data
`
`Packet
`
`.1
`I
`I
`
`Payload Packet
`
`Carrier Packet
`
`Payload Packet
`
`Encrypted
`Payload Packet
`
`Carrier Packet
`
`Figure 18.21.
`
`Tunneling: (a) Secure packet; (b) IP-over-IP; (c) Secure Tunnel
`
`Let us start by understanding what a tunnel is: the encapsulation of a whole
`payload packet that circulates in network A, in a carrier packet, that circulates
`through network B, until network C, where the carrier packet is de-capsulated
`and the payload packet circulates again until the final destination. A classical
`tunnel is IP-over-IP, whose packet structure is depicted in Figure 18.21b.
`It
`consists of encapsulating a full IP datagram as if it were an upper layer service
`data unit, in another IP datagram. A secure tunnel is then a tunnel that
`guarantees the properties of a secure channel to the data carried inside it.
`Figure 18.21c suggests how it can work: the whole payload packet is treated as
`
`Exhibit 2026 Page 490
`
`

`

`MODELS OF DISTRIBUTED SECURE COMPUTING
`
`477
`
`a block of data, and is encrypted and/or integrity protected. The result is then
`treated as data and encapsulated in the carrier packet. In the final destination,
`the operations are repeated in reverse order: the outer packet is de-capsulated,
`the data decrypted/verified, and the inner packet launched on the network for
`IPsec (see Section 19.3) is the forthcoming standard for
`its final destination.
`secure channels and tunnels on the Internet.
`
`18.10.3 Distributed Authentication and Authorization
`
`Among the several functions that assist secure computing, two are fundamen(cid:173)
`tal: authentication and authorization. We studied th