BOBOpdHHHHHHHj (-Z Perry The CynicfBLOM!`ݯRxHHLXG(HH(d'` " l@/z|8"0"|zn"0   4[IDSETb ""k!$"&=B o"+O4C"' ^#"':B /"`(H@ 9"<,D6" -jQr"P%-6[\"+[g`"4 P $D   n  9I  Q>V 2     ! p  !      .   ! -  j! ! $!$ %% ' ' ) ) *= , !, . /( /!/ ////0!0112v!244!56!688 :q < == ==>>>I >>>!> ?!@ @ @@ACAp AABBb BB CGCwC D6 D~DEEzEFF H I!I L? Mu N P5!PO RR S T6TvT!T U:UVCVW!WXXYfYZZ?Z[A![\\\]]W]^^i^```a!abcddfP!fkg`!guh!h ie!ix jk!j k `$D A  V    N  c 9I    >V                   "  7   %         %   6 I              P Q    % K N g h j %     ! ! #A #B $ %$ %  % %% %  % '* '3 ' ' ) ) )  )  ) ) * * *  * + + + + ,  %, ,<  ,D ,  , / / / %/ / 0 %0 0 0) 0- 2P 2W 2v %2 2 2 3  3# 3C 3D 4 %5 5 5 5 5 5 6 %6 6 88 8 8 8 9 9 :?  :D :  : == = >I > > %> ? %@ @ @ A Ap A B Bb BB CG C D~ D D D D E FF G  G# I %I J  J0 Jv Jw J J ML MT N N P5 %PO Q Q RR R  R R R T6 T T T %T U: US Ue Ur U} U V% VC V W %W X Yf Y Z [= [> [A %[\ [` [z [ [ \ \ \ ] ] ] ^ ^  ^i ^o ^ ^ _, _1 ` `` a %a a a b b c d d d fP %fk g` %gu h %h ie %ix jk %j `z n8PF Tg n #A  ' T * z& / 3Cn&9JvRlTz[=[J2 1 d<5YLhh >#L'{+h|/%35D8VX;t?TCHGn`K4NTRP8V8GYH\\P`vLD` `dMh8Insight Access Control Architecture (Using ACLs for Fun and Profit) This document describes the overall access control architecture of the Insight design. Note that we focus here on access control and authentication (to an extent); this is not the general architecture document. For the general Insight architecture, see Architecture Overview. For a general introduction to ACLs in the CDSA framework (independent of Insight), see ACLs in CDSA. It may be that this document contains more general architecture information than intended. Some of this content will eventually migrate into the Architecture Overview document. The contents of this document are by necessity somewhat recursive. Please read the whole thing before giving up. Thank You. At the end of the document, you will find a list of open questions and issues. Design Criteria This design tries to satisfy the following goals and requirements: Keep sensitive key bits away from any but the most trusted system components, while allowing the controlled use of these keys Allow complex access control configurations, potentially different for each protected item, while keeping the default case simple to understand for the user Support database portability (portable user secrets) Support smartcards as cryptographic computation and secure storage media, even if they have limited storage capacity Provide single sign-on functionality for keychains between user applications on one computer, in the sense that keychain pass phrases only need to be entered once for use by multiple applications (as configured by the user, of course) ACL Strategy (Overview) The Apple CSP/DL plugin module manages ACLs for database access and for database items of type key. We do not currently plan to use the CSP login function on our CSPs, and therefore CSP login ACLs are not implemented. For databases managed by the Apple CSP/DL, storage items that are keys have their ACLs stored along with the (encrypted) key bits, in a form that is partially encrypted and wholly signed. This allows the ACLs of keys in a locked database to be read (sans the private parts, which are never returned by ACL read functions) without exposing private elements of the ACL to unauthorized access. ACLs are read into memory along with the (encrypted) key bits of their key object. Once the database is unlocked, the ACL can be verified against its signature, and its private parts can be accessed for ACL evaluation. These sensitive operations are performed in the micro-CSP (uCSP), which protects them from application snooping and interference. Note that from the CSSM point of view, all non-key items in a database managed by the Apple CSP/DL are stored in the clear. The Secure Storage layered service (described later) can provide confidentiality and/or tamper protection for such items. The Apple CSP/DL The standard Apple CSP/DL is a multi-service CSSM plugin module that provides combined CSP and DL functions. It can manage temporary and permanent keys. All its permanent keys are stored in its own databases. CSP Services The Apple CSP/DL implements its cryptographic (CSP) functionality through a combination of internal services and through an interface to the uCSP daemon. The specific division of labor is that any information that the application (that called CSSM) has generated itself, or can reasonably gain access to, may reside in the CSPs local storage, and may be operated on there. Any other information must be held in the uCSP and processed there, with only results of the processing being returned to the CSP proper. This rule ensures that a corrupt or malicious application cannot gain access to information through memory hacking. Specifically, that means that sensitive keys will generally reside and remain in the uCSP, while non-sensitive keys may freely be moved between CSP and uCSP as needed. It is ultimately the users responsibility to make the choice of sensitivity, though of course the layered services will make this determination in most cases. Typically, digesting and cryptography with session keys will take place in the CSP, while signing and key generation will be reserved to the uCSP. Happily, this means that bulk operations involving large amounts of data need not be done in the uCSP in most cases. It is our intent to implement full cryptographic services in the uCSP, so that e.g. sensitive session keys can be supported. This will have some performance penalty in CSP/uCSP communications overhead, but it is a decision that must be available to the caller. DL Services The Apple CSP/DL implements its databases as flat files on disk. Each database has an associated database master key that is used to encrypt all key items stored in it. All other item types are stored in the clear. The master key is encrypted with the databases pass phrase and stored within< the database file. Each database also has a database signing key that is used to sign portions that are not encrypted but must be protected from tampering. The signing key is stored in the database file encrypted with the master key. Finally, the ACL for the database itself is stored in the database itself, partially encrypted and signed with the database master and signing keys. Only private parts of the ACL are encrypted. All of the ACL is signed. When a CSP/DL controlled database is opened, the DL retrieves the encrypted master key, signing key, and ACL from the file and passes them to the uCSP for management. At that point, the uCSP becomes responsible for managing the master key; the CSP/DL never sees its clear bits. The uCSP will contact the Secure User Interface facility to prompt the user for the databasesY pass phrase as needed. Note that the CSP/DL never sees the pass phrase. The uCSP will also retain the clear text master key and manage it according to requests from the CSP/DL. Similarly, the DL retrieves the encrypted data of keys stored in the database as needed and passes them to the uCSP for handling. It is the uCSP that decrypts them as needed. The uCSP observes all restrictions imposed on a key (such as the sensitive and extractable attributes), and only returns them to the CSP/DL as allowed. ACLs for keys stored in the database are retrieved along with the encrypted key bits and are passed along to the uCSP . The uCSP is solely responsible for evaluating ACLs and enforcing the resulting restrictions. Note that the public parts of ACLs are readable on disk without possession of the master key, and can be returned to user queries even if the database is locked. The Micro-CSP (uCSP) The Micro-CSP (uCSP) is a system-unique privileged daemon process that provides secure cryptographic and related services to all interested processes . It has no public (user visible) interfaces; its only intended client is currently the Apple CSP/DL plugin module . On OS X, uCSP is a trusted system process that is launched during system startup, and can be contacted through a privileged IPC port. This ensures that an attacker cannot substitute (spoof) it with another version. It is up to the uCSP to suitably authenticate its caller. Cryptographic Services The uCSP provides cryptographic services exclusively to service requests from Apple CSP/DL plugin modules in other processes. The interface is based on IPC (and possibly shared memory for block data transfer), and is not based on any standards in particular, since it is a private agreement between the CSP and uCSP. The uCSP stores sensitive keys and ensures that any extraction operations obey the CSSM restrictions on sensitive and extractable keys. It acquires keys from a CSP in wrapped (encrypted) form, and acquires passwords through protected paths from the Secure User Interface. The uCSP does not store any keys across system restarts; permanent keys are encrypted and handed to the CSP/DL for storage in database files, along with their ACLs. Note that uCSP itself does not use CSSM for its operation. It does not contain a CSSM stack and does not use CSSM plugins of any kind. Master Database Key Management and DL Support When the Apple CSP/DL opens a database, it transfers the (encrypted) database master key and master signing keys the uCSP. When the CSP/DL tries to use a key in that database, the uCSP tries to obtain the database pass phrase via the Secure User Interface facility. Once acquired, the uCSP holds the decrypted database master key for further use. The uCSP implements certain simple policies for when to forget the (decrypted) master password for a database. There is at least an explicit interface to do it immediately (which locks the associated database), and a timed (idle) facility. Note that this function of the uCSP is specifically to support the Apple CSP/DL plugin module. The interface is private between these two parties, and the service is not intended for any other use. The handling of database master keys is highly magical, and does not conform with rules for ordinary CSSM keys. In particular, the master key has no ACL. On the other hand, the process allows keys stored in such a database to be handled securely, and their ACLs to be applied as per standard, without the need to have secured storage for the database files. ACL Evaluation The uCSP holds and manages the ACLs for all keys it stores. It acquires key ACLs from the CSP/DL in partially encrypted and signed form, and verifies their integrity internally against their signing key before using them. From then on, all access to the underlying key is allowed only if its ACL permits it. The uCSP understands all ACL subject types described below under ACL Implementation. Secure Storage Layer A layered service, called Secure Storage, is used to access and control keychains. In collusion with the uCSP, this service provides for secure storage of confidential information on unsecured media such as local disk, file servers, and remote databases, as well as providing convenient access to collections of these storage units. Secure Storage is the keeper of keychains. Keychains are generally created, accessed, modified, and manipulated through Secure Storage APIs, or through layered services that use it. Secure Storage creates the fiction of access control for non-key items in keychains by using CSP/DL modules to encrypt or sign these items with keys stored in keychains. In CSSMs view, non-key database items are cleartext. Secure Storage imposes encryption on item data, stores, and manages the resulting ciphertext in databases. Keychains A keychain is a logical storage medium for user data of various security sensitivity. There may be any number of keychains on any given system, owned by any number of users. Keychains are constructs of the Secure Storage layered service, which implements them in terms of CSSM DL/DB databases. A single keychain is implemented as one or more CDSA databases (DL/DBs) . The Secure Storage layered service API integrates these databases into a logical whole, and manages access to its elements, each of which is a storage item in a database. Databases that permanently store cryptographic keys must be managed by a CSP/DL plugin such as the Apple CSP/DL. Databases that store non-key items only can be managed by any DL plugin (including the Apple CSP/DL). Keychain Locks Conceptually, a keychain is in the unlocked state if the uCSP daemon holds the decrypted master key for its database. Otherwise, the keychain is in the locked state. To unlock a keychain, the uCSP acquires the keychains pass phrase and uses it to decrypt the master key. To lock a keychain, the uCSP simply throws away the decrypted master key. Naturally, a locked keychain cannot access its encrypted items, while an unlocked keychain can give access to them, after validating access through an items ACL. The uCSP maintains a per-keychain policy for locking. At minimum, there is an idle timeout period. If that amount of time passes without a keychain item being accessed, the keychain is locked. There is also a CSP/DL passthrough command to immediately lock an open keychain. Note that closing a database does not necessarily lock it, for reasons of user experience . Keychain Contents Conceptually, a keychain may contain any number of four kinds of items: Key Secret Public unprotected Public tamper-proof Key Items Key items are keys in the CSSM sense. Key items are always encrypted in storage using the keychain master key. Access to key items is controlled based on the keys ACL. This is done by the CSP/DL plugin (in collusion with the uCSP). A key items ACL is stored in the database along with the (encrypted) key bits, and is signed using the keychains master signing key. Note that keys are not the same as passwords. Key items are those that are directly involved (as keys) in cryptographic operations. Confidential items that are not locally used in cryptography are Secrets (see next section), not keys. Secret Items A Secret keychain item is a confidential storage item that is not a CSSM key. Secret items are encrypted in storage using a key item stored in the keychain (not the master key of the keychain). Access to the Secret items plaintext is thus controlled by the ACL of the encrypting key. The Secure Storage layered service translates this transparently into access permissions for the encrypted secret. The secrecy of secret type keychain items is provided by the Secure Storage layered service. It is not a function of the CSP/DL, though the CSP/DL manages the underlying key that is used to encrypt the item data. Public Tamper-Proof Items Tamper-Proof items are stored in the database in the clear, but are signed to protect them against unauthorized alteration. Like Secret items, this type is created by the Secure Storage layered service, and uses keys (items of type key) stored in the keychain itself. Access to tamper-proof keychain items is gated through the ACL of the key used to sign them. Note that read access to these items is implied; it cannot be made conditional or forbidden. Public Unprotected Items Public Unprotected items are stored in the database in the clear, and are not protected against malicious modification. That means that there is no protection against a hacker making changes to a database file (on disk, over the network, or wherever it might be stored) to modify the items value. Unprotected items are fastest to read. This is also the appropriate item kind for objects that are self-verifying, such as certificates. VAccess Groups Secret and Tamper-Proof keychain items are implemented by encrypting or signing the item data (but not attributes) with a key stored somewhere (typically in the keychain itself). There is no reason why multiple items cannot be encrypted or signed with the same key. Access to all these items is then controlled by the same ACL, that of the encrypting key. From a users point of view, this looks exactly like a group of items with identical access permissions. We thus create a user interface feature called Access Protection Groups. Each group is represented internally by a key stored in the keychain. Changes to an items access permissions will apply to the entire group, since they modify the encrypting keys ACL. Naturally, it is possible to create a new group by generating and storing a new key, and to move an item between groups by re-encrypting it with a new key. It is not clear whether item groups should be a basic or advanced feature of the user experience. If the choice is to make them advanced (only), then by default each item should reside in its own group (have its own key) and thus have its separately controlled access rights. If groups are judged to be basic, then new keychains may come with some predefined groups. ACL Implementation The following standard ACL subject types are implemented by the Apple CSP/DL: Password Protected Password (using the Secure User Interface facility to obtain the password) Public Key In addition, this CSP/DL implements nonstandard specific subject types for the needs of its databases: Application Digest User Protected Prompt Application Digest Subject The Application Digest subject type specifies that the application making the request must be a process instance launched from the application with the given digest. The corresponding sample type provides the location on disk of the application. User Protected Prompt Subject The User Protected Prompt subject type specifies that the user should be asked, using the Secure User Interface, as to the disposition of the access request. The SUI is given this information: Application name and identification The CSSM authorization tag describing the operation for which the ACL is being tested Prompt information included in the ACL entry It may respond in three ways: Accept the subject is authenticated and associated authorizations apply Reject - the subject is not authenticated and the subject match fails Retry - the ACL may have been modified, so it should be reprocessed Note that the Retry return is slightly magical in that it alters the processing of an ACL matching evaluation. ACL Patterns When a new key item is created through the Secure Storage layered service, its ACL is by default set so: Owner = Digest of Keychain Access Application ACL = User Protected Prompt This means that for a freshly created key, only the Keychain Access application may change the ACL, and any access invokes user interaction to confirm access. Keychain Access may reconfigure the ACL in the following standard ways: Add application digests to permanently allow access by certain applications Remove the User Protected Prompt entry to permanently disallow user interaction Add application signatures to the owner subject to allow certain applications to modify the ACL Add User Protected Prompt to the owner subject to allow the user to individually permit ACL modification by other applications Note that in expert (custom) mode, ACLs can be modified arbitrarily to contain any entries and any owner. It is the responsibility of the (presumably expert) user to understand the consequences of such configurations. The Keychain Access Application A particular application, called Keychain Access, is by default charged with managing access control of keychains for the user. Its job is to present ACL-based access control configurations to the user in nice ways, and allow an authorized user to change ACLs to implement various access policies. ACLs are a fine way to describe access rights and their conditions. They are not well suited for human consumption, particular of naive users. It is Keychain Accesss job to mediate between these two forms. Keychain Access has a predefined set of standard access control configurations that the user may choose from; each corresponds to a pattern of ACL entries that implements this configuration. How Keychain Access Operates Keychain Access can be invoked directly by the user, or can be invoked through the Secure User Interface if the user requests to make (permanent) access configuration changes . In either case, it proceeds to work on one keychain item (or one Access Control Group of items) at a time, corresponding to its encrypting (or signing) key. It reads the ACL for the key and tries to match it against its built-in set of access control configurations. If the ACL content matches the pattern for one of the built-in configurations, that configuration is indicated as active. If none match, the configuration is shown as custom (expert). The user may then make changes with Keychain Accesss user interface as desired. No changes are made to the object ACL until the user commits these changes. If the user cancels, no changes are made. If the user commits, the ACL pattern corresponding to the user choice replaces the current object ACL setting. Keychain Access offers a custom setting to the user. In custom mode, ACL entries can be directly edited. This option is intended for expert users (and developers) only, and requires understanding of CSSM ACLs and their use in our software. If a custom setting is committed, the object ACL is updated as requested. Note that Keychain Access, by default, is the owner of the ACL of every key object created through Secure Storage. As a result, only Keychain Access can change access permissions on key objects (and thus, by extension, databases). Keychain Access provides the ability to change or augment ownership of object ACLs to include other applications, or (in expert mode) any valid ACL subject. Replacing Keychain Access Please note that there is nothing inherently special about the Keychain Access application delivered by Apple. It runs under user UNIX permissions, without magic rights or privileges. It derives its special status solely from the fact that it (its digest) is the owner subject of key object ACLs created by Secure Storage. It is perfectly possible to substitute a third party application in that role. The Secure User Interface should simply invoke whichever application is noted as owner of the ACL in question, and we could document the interface it uses to invoke Keychain Access. The Secure User Interface Facility The Secure User Interface module provides sePcured interaction with the user. It exists to provide security from snooping and spoofing of sensitive information prompts, and as implicit authentication of the users presence and consent. We anticipate that the SUI will eventually become useful to other parts of the system. Initially, however, it serves two purposes for Insight: Securely prompt the user for a secret (password or pass phrase) Securely prompt the user to decide on an unconfigured attempt to access a key General Security Requirements To provide secure user interaction, the SUI must implement and follow a set of rules: It must be invoked by an out-of-band signal, or else be watermarked in some obvious way It must use a trusted path to the physical I/O devices (input devices and display) that cannot be snooped or disrupted by other code in the system while a prompt is iGn progress Note: A companion document will describe the Secure User Interface facility in detail. Please note that these requirements do not provide security against hardware attack. In particular, someone who can replace an input device (e.g. the keyboard) can certainly snoop passwords and generate rogue input through it. They do however provide protection against non-root processes impersonating or observing the user interaction. Secure Prompt The Secure Prompt function offers a modal dialog to the user, displaying context information and asking for entry of a password or phrase. The dialog gives the following information: An arbitrary prompt string (describing the nature of the password requested) The identity of the requester (as derived from the manifest of a signed application making the request) The user may choose the fHollowing actions: Enter a password (visually protected) and accept (OK). The password cleartext is delivered to the requester. Decline (Cancel). The requester is notified of cancellation. Obtain more information, by investigating the requester and other information provided. Note that while it is possible for an unsigned application to make a Secure Prompt request, the result is meaningless for security, and the user should be so informed . Unconfigured Access Dialog The Unconfigured Access Dialog function offers a modal dialog to the user, displaying a description of a security-sensitive operation whose access control configuration requires user intervention to proceed. Specifically, the uCSP will invoke this function while evaluating ACL entries of the (Apple specified) User Protected Prompt subject type. The dialog gives the following information: A description of the object whose use is being requested An arbitrary prompt string (generated by the requester) The type of operation or access being attempted, as indicated by the requester as a CSSM authorization tag The user is given a choice to, at least, do one of the following: Reject the access without making permanent changes. A rejection notice is returned to the requester. Accept the access without making permanent changes. A consent notice is returned to the requester. Invoke a configuration facility to change the objects security configuration. This invokes the owner application of the object as indicated by the ACLs owner subject (usually Keychain Access) and instructs it to present the objects current ACL to the user. The user may then make permanent changes to the objects access control list. It is possible for the Unconfigured Access Dialog to offer additional, frequently usefulL options that are combinations of the above. This should be done with care. Open Questions Here are some issues that are, as of this writing, unresolved, undefined, or under contention. Feel free to weigh in on the discussion - if you stay silent, you will have to live with the result! The Nature of Keychains Exactly what are keychains? Are they (DL/DB) databases, or are they a logical construct implemented with (one or more) databases? Put differently, is every DL/DB database managed by the Apple CSP/DL a keychain? Since we want to be able to store keys separately from some non-key items (e.g. to combine keys in a smart card with data in a remote database), we need to be able to correlate multiple DL/DB databases as a cohesive whole. The major design alternatives are Make this look like multiple keychains, accepting that now keychains are no longer independent, and loss of one may make another useless, or Make this look like one keychain, accepting that now a keychain does not have a single physical manifestation (one file, one smart card, etc.) Indirectly, this design option also determines Mthe role of the Secure Storage layered service. If keychains are logical entities, then Secure Storage should be their manager and implementor. If keychains are DL/DB databases, then it is merely a utility layer that implements item encryption, and keychains are shaped, one hopes cooperatively, by our CSP/DL plugin, by Secure Storage, by Keychain Access, and by other layered services. Database Item Initial ACLs What are the initial ACL owner and access slots for an item created through the Secure Storage layered service? Is there a way (through the Secure Storage API, or through user preference configuration) to influence them? How and to what extent? Database Key Details How are the database master key and database master signing key related? Is the signing key derived from the master key, or are they both generated independently? This stuff needs to be worked out, if for no other reason than to make sure there are no hidden defects lurking there. Access Control Groups Should we present Access Control Groups to the user as a basic feature, or as an expert feature that is hidden unless explicitly invoked? Or should we hide it altogether in the first release? uCSP Extensibility The uCSP is a very special security construct, and it is private to the Apple CSP/DL. What means can we offer our developers to provide equivalent security for modules they write? Can we offer part of the mechanics for them to share, and how? Keychain Event Notifications How can a keychain client be notified when the uCSP locks or unlocks a keychain? There is currently no good notification mechanism in the CSSM framework. We may want to augment the module event insert/remove/fault mechanism to deliver database-specific events. This would presumably require adding a context field to callback events. ZNDSETTh`" <       Note that in CDSA, only key items in CSSM databases have ACLs associated with them. Any other types of items in a database do not.DSETT`  "    All our stock CSPs will actually be multi-service CSP/DL modules, since plain CSPs cannot conveniently represent permanent key storage.DSETT`x"    At least on OS X.DSETT`\H"   ( This somewhat UNIXoid term means that we do not use a database management library, but implement our own storage organization.DSETT{`{<0,"   |4| Alternatively, the signing key could be derived from the master key. Under no circumstances can the two keys be the same.DSETTB`B"   CC The format of key ACLs is identical to that of the database ACL.DSETTV`V"   WW Whether and how the uCSP can provide services to kernel code is not clear as of yet.DSETT,b` n"   oo Layered services access some functions through passthrough methods of the plugin, e.g. to lock a database.DSETT` "    In theory, it could be using an AC type module to evaluate access controls. The current design, however, envisages dedicated ACL evaluation code to be used.DSETT` "     In some vague sense, the database ACL can be considered an ACL for the database master key. However, this is not technically true, and the authorization tags in database ACLs are different from those for keys.DSETTU` U݈"|    V݄V The legacy keychain interfaces are supported by, or built on top of, Secure Access.DSETT` x݀|&"x& 0     t There is unsettled discussion on whether such multi-database keychains should actually appear to the user as multiple keychains, or as a single keychain with distributed storage. See the Open Questions section at the end of this document.DSETTg`g"" ""    h"h It might be a useful configuration option to lock a database when it is no longer open by any client.DSETT`hpl&"t& 0  9 A  d Actually, they could be encrypted by a key item stored anywhere, including in other keychains. Whether we will actually implement this ability is undecided. If multi-DB keychains are presented as multiple keychains, this may be unavoidable. See the last section, Open Questions.DSETTy6`y"`""p   z"z Using different salts or initial vectors, of course. Also, signing and encrypting should not be done with the same key.DSETT`""""l   " SUI does not know Keychain Access by name. Rather, it invokes the application that is identified as the owner of the ACL being processed.DSETTL`""""h   " This facility will initially be a combination of daemon process and system support calls. In future versions (of OS X), it may be implemented in different ways, e.g. as kernel system calls.DSETT`>""""d0   %  ?"? This was called the Rogue App Alert in the previous version.DSETT'-`S""""`   T"T E.g. An application claiming to be Eudora Pro wants you to enter a password...DSETT`""""\   " The name is a slight misnomer, since the user may explicitly configure this dialog to appear. Better names, anyone? And no, Rogue Application Alert isnt on offer...DSET.H"ZP6*ZDSET .H/(/"|Z   00@@P 6*ZDSUM(Perry The CynicHDNISTYLIDSTYL"l"@"h"`"X"P"H"D    F ):   H :T          4     " $& '%()0(( *0((+0((,0(*-0(*.0(* /0(* 00(* 10(*  20() !30()"40(+#50(+%$6%7066&8066'9066(:068);068*<068 +=068 ,>068 -?068 .@067/A0670B069 #1C069%2D3E0DD!4F0DD"5G0DD"6H0DF#7I0DF$8J0DF$ 9K0DF$ :L0DF$ ;M0DF$ <N0DE%=O0DE%>P0DG#?Q0DG$%@RAS0RR&BT0RRCU0RRDV0RT' EW0RTFX0RT GY0RT! HZ0RT" I[0RT# J\0RS($ K]0RS(% L^0RU& M_0RU'%N`(Oa0``))Pb0``*Qc0``+ Rd0`b,Se0`b-Tf0`b.Ug0`b/Vh0`b0Wi0`b1Xj0`a*6 Yk0`a*7 Zl0`c 4 [m0`c5 \n(]o0nn) P^p0nn*_q0nn2`r0np,as0np3bt0np8cu0np9dv0np:ew0no+6 fx0nq<gy;hz0yy,=i{0yy>j|0y{ k}0y{!l~0y{"m0y{#n0yz-Ao0yz-Bpq8r8s8t8u8v8w8x8y8z8{8|8 }.!~8/"80#81$82%82&82'82(82)82*82+, 8-8.8/8081-3243     9  9 8 88 5  G     " 61#!0! #8%!8   5 5 6 F    6"6 9696 6<8* 8 8 8 7 7 8<886HASH $(( (*) ( ( ( )ô׌Nô،\/*&(&) $2Ҵ"<"%8g@n:7(5(QQA,Qv,qQrvstuv w/xTyyz{|,8~QIv4555 5 * /5 T5 y5&)*+,-10"OJPKC U!. / 08 19 2: 3;CeJXKY (4 G0 5(y>y<?= H?'B6 $5 37JA> EO>]3%i-F.G/H0IFL`D/T0U1V2W0[JZ&E.M "B #C $^ %_lmjk*noHf/S9c:d1`7a8bDR0h'Q *% &C 0$C 0( I)01L:Qfeg}hmhiCodjaqit rl tuzoz}Bod}p=; CHAR"d         7" 37  8  "  " ( ' %         .   "  !/ * 2 &/  )  ,& &  & .&  7 7      " ,HASH-01124/E0:"+3:%;(D')*# $ )* *    36F4H5L R 9     6 $-</7 RC? CELL"\97'          x $ x                @ ( s @HASH     $ % 67(xx13   )  >  ! " #&' ./01 45;*2*AB= -,<389: +  GRPH"T7G   |HASH      ; l RULR"L@\@&f $7$@ @f@  B@ $$Hl D h  $Hl D h$Hl>+~@f$+$  f9HASH8 ("&5"- 6@  k2,':,-Q.v/010 ,Qv! /Ty ,"Q#hv$%&' ( /) T* y+ 09h4@@BB Bh H  H3LKUP   !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~"$NAMEDefault Default SSHeaderBodyFooterFootnoteFootnote Index BulletTitle Section 1Q & AQQA" Definition$Code& Checklist'Number(Classic6 Blue Gray 1D Blue Gray 2RColorful` 3D Table 1n 3D Table 2y AccountingHarvardLegalDiamondEmphasisFilename CodeLinesWarning Doc ReferenceSubtitle# Section 2dDFNTM HelveticaGenevaCourierTimesPalatinoMCROMCROoBlNoBlNBBARBBARMARKMRKS MOBJWMBTETBLXDSUMDHDNItSTYL~MCRO|oBlNBBARMARKWMBTETBL