IntroductionSelf-administering Data Handler ModelNetwork of SDHandlersScalable Update Propagation ModelSelf-administering Data Delivery ProtocolAuthentication and AuthorizationDefinition of Data-DomainData-Domain vs. RealmAuthenticationAuthorization (ACL per Data-domain)Replay AttackData IntegrityForward/Backward IntegrityUndo/Redo with VersioningConfidentiality (Privacy)Content Confidentiality (Snooping)Hybrid MethodForward/backward SecrecyTraffic Confidentiality (Traffic Analysis)Periodic Connection Avoiding Traffic Analysis: MixesAvoiding Traffic Analysis: Anonymous RemailerAvoiding Traffic Analysis: Rendezvous ServerVulnerabilities to computer virusesComputer Viruses and their characteristicsPolicy against Computer Viruses in SDHDiscussionReferencesSecurity Issues in Inter-Domain Data Management B. Hoon Kang Division of Computer Science UC Berkeley Berkeley, CA 94720 [email protected] Jaein Jeong Division of Computer Science UC Berkeley Berkeley, CA 94720 [email protected] ABSTRACT We discuss the security design issues in providing secure updates to the write-shared object among users across different administering domains. In general, it is difficult to assume a dedicated central server for serializing updates and authenticating collaborators in a write-write sharing across administering domains. Hence, we have proposed a decentralized inter-domain data management method, which has been exemplified in Self-administering Data Handler Model [1] . This paper discusses security issues of the SDH: the authentication (identity), the authorization (access control), the data integrity, content confidentiality, and the traffic confidentiality. We also discuss that the SDH model is not more vulnerable to the computer virus attack than other inter-domain applications. 1. Introduction Traditionally, Network File System provides a model of transparent file access/management semantic that allows the user to access/manage remote files in the same way as local files are accessed. In most real implementation such as Sun’s NFS, Sprite File System, and Andrew File System, read/write caching is used to provide such transparency to the user by amortizing the network delay over multiple subsequent reads or writes. For example, in a typical write-write sharing of remote file between more than two users, each user’s write is immediately applied to the write cache on their local machine and waits 2-30sec (Sun’s NFS) or 30sec (Sprite FS) to absorb any subsequent writes before the written-cache is sent to overwrite the original remote file. The model of transparent file management has limitations. First, although each user keeps their most-recent update in their local cache, they cannot undo or redo their own update. If they maintain explicit copies and its versions instead of the most-recent cache, the redo/undo/versioning can be done locally without involving remote repository. Second, in this model, one of the collaborators has to dedicate a shared resource that serves as a file repository to provide a single coherent view among collaborators, which is not feasible all the time especially across different administrative domains. Each domain (realm) likes to maintain their own explicit copies rather than implicit caches that depend on a centralized shared repository. We have proposed an inter-domain data management protocol as exemplified in Self-administering Data Handler Model [1] . In this paper, we address the security issues of the SDH: the authentication (identity), the authorization (access control), the data integrity, content confidentiality, and the traffic confidentiality. We present the data-domain concept and compare it with the concept of realm in Kerberos [2] [3] . In traffic analysis section, we proposed a radical approach using a “rendezvous server” to deter the traffic analysis based on network packet header. We also investigated whether the SDH model is more vulnerable to the computer virus attack than other collaborative inter-domain applications such as email and web browser. 2. Self-administering Data Handler Model In this section, we briefly introduce the SDHandler (SDH), as an inter-data domain data management mechanism that we proposed in [1] . In this model, the SDD(Self-administering Data Description), a declarative description of how a data object should behave, is attached to the data object. The description specifies how and to whom the data should be transferred, how it should be incorporated when it is received, and the kind of relation that should exist between distributed copies of the data object. 2.1 Network of SDHandlers As shown in [1] , we envision a network of SDHandlers, each “close” to a user or device that it serves. To a first approximation, there would be one SDHandler per networked device, perhaps more. Some would be associated primarily with users, some with data collection in devices, others with services, such as digital object repositories, each supporting basic SDHandler functionality, but perhaps implementing services associated with the particular characteristics of its application. Such a network is illustrated in Figure 1. SDHandlers form a network, within which data is moved in accordance with the SDHandler’s discipline. In addition, each SDHandler may provide an interface to a local collection or stream of data. The data may be a user’s file system, web space, database, or other collection, administered by some mechanism other than the SDHandler. While these may be administered by a wide variety of mechanisms, the data looks the same once itis with the SDHandler network. We refer to each diverse collection of data as a data domain. In effect, the SDHandler bridges a data-domain into the SDHandler infrastructure. User A Service Providers:On-line StorageSD HandlerDevice D:Pervasive Sensors/Actuators,PDA, Camera, ScannerUser BSelf-administering Data Delivery ProtocolSD HandlerSD HandlerSD HandlerCentralized Services:Strong Serialization, Store-and-forward deliveryPartitioned(Local)Versioning,IndexingPartitioned(Local)Versioning,Indexing Figure 1: Network of SDHandlers 2.2 Scalable Update Propagation Model We have developed a scalable update propagation model based on cliques. We define a clique as a strongly connected group of users who share the same SDD (Self-administering Data Description). SDD is meta-data describing how the data should behave, to whom the data needs to be
View Full Document
Unlocking...