Download
1 / 49
490 likes | 715 Views
Dimensions of Security. Mechanisms, Architectures and Politics. Walter Kriha, Hochschule der Medien Stuttgart. Warm-up: What can we learn from the T-COM OBSOC disaster? Threat models and security awareness
E N D
Dimensions of Security Mechanisms, Architectures and Politics Walter Kriha, Hochschule der Medien Stuttgart
Warm-up: What can we learn from the T-COM OBSOC disaster? Threat models and security awareness Dimensions of Security with examples (SSO, health and job card, dialers, trojans and the problem behind, e-voting) Beyond fear: why security itself is becoming a major risk (on stupid and dangerous security) Agenda The focus here is on understanding security in context of real problems. Security mechanisms and technologies are introduced as we go along. Please ask if something is not clear.
Learn that security is an awareness problem show some security problems and how they can be analyzed and solved show that designing security solutions is a highly social process – with respect to developers as well as end-users discuss the political role of security nowadays Goals It-Security is so appealing to some because of its complexity, human involvement, organizational procedures and political consequences. For others it is a nightmare for the exact reasons. And some try to reduce its complexity by focussing on some aspects only: network, firewall, crypto etc. and by doing so loose it completely.
OBSOC – the T-Com partner and contract web application application server application server customers web server Internet OBSOC infrastructure admins Partner Services Test machines This diagram is a conceptual reconstruction after reading the CCC documentations. OBSOC is a rather typical web application which allows customers and t-com admins to maintain and control customer data and associated services. It qualifies as a „self-service“ application in e-business patterns speak. In August several severe security problems where detected by Dirk Heringhaus (see resources) which affected customers and external and internal services as well. The service had to be taken down and is offline since!
Changing URLs allowed to work around authentication and authorization (no client data validation) Password handling for customers and admins was way below standard and allowed easy password guessing (wrong protocol, weak procedures) Customers and Admins used the same entrance with the same low level security (wrong design) Implementors of OBSOC held critical data, e.g. SQL-Server backups on private domains, including domain passwords. (Developers lacking basic security principles) It was possible to break through from web application space into windows domain space.(Infrastructure unsafe) OBSOC Security Problems from D.Heringhaus (see resources). ConPK=vvv would change to a different user contract It was easy for anybody to take over other customers data, e.g. to order new services or stop existing services. Direct access to internal windows domains was possible from the internet. It should be clear that the OBSOC problems are much bigger than finding a specific security glitch in a firewall or application server – as it can happen anytime to any company.
OBSOC Security as a System Protocol Implementation Procedure No security Sign-Off No security standards and procedures No incident response in place Wrong authentication protocol for admins Lack of access control Weak password handling No filters No clean software architecture Security is the result of a multi-dimensional effort. OBSOC failed in all three dimensions.
Basic Mistakes and Advanced Frameworks Mistakes .NET Platform • Web services • legacy integration • transaction enabled • XML support • High availability • ASP+ • no input validation • weak and faulty authentication • no authorization architecture • unprofessional behavior with respect to • critical data • organizational problems in case of security bugs • no secure development process Is it the platforms fault? Huseby mentions interesting „features“ of ASP/PHP like automatically assigning variables or performing automatic lookup in different places but this was probably not the case here. The mistakes are too basic for this. A different question is: did the developers UNDERSTAND the security features the platform offers? Where they overwhelmed? There is a really stark contrast between the level of mistakes and the high-tech platform used.see: „Using Microsoft...“ in resources
Security by Framework Security features provided Problem areas • creating a choke point for authorization (e.g. in Struts) • input/output validation with descriptive customization and external verification (e.g. in firewalls) • context sensitive access control • organizational issues like key handling • Support for sessions • separate authentication • authorization interfaces • infrastructure integration It is now common understanding that development platforms need to separate security from applications as much as possible. This happens through separation of concerns and context like in EJB/J2EE. But support for security is not yet complete and understanding of the features on developers side is critical.
IT-Security expertise split between network and software people Lack of security awareness especially on developers side Deadlines and user comfort more important than security. Organization not geared toward secure products. Explanations The network security people are slowly getting a better understanding of the software development process and critical pieces like interfaces and protocol definition. And software developers need to get a better understanding how network security, application security, host security and user security are related.
Cryptographic Algorithms Security Protocols and Mechanisms Security Policies/Principles Frameworks Domain Problems (e.g. web) Security as an Awareness Problem web application ? Most developers have a hard time to map the left side to the right side. They do not see the security problems in the real application and therefore do not profit from knowledge in cryptography. Worse, because they usually do not know a lot about infrastructure (network and firewall security) they tend to overestimate the security provided through those means. Actually, very few companies use intrusion detection or tiger teams. This should influence the way we teach security: starting with the problems of applications and introducing security mechanisms and solutions as needed.
Threat Models User conceptual model bespoke applications peer-to-peer model network/internet threats host security client side host security server side Historically threat models started with a focus on host security: (trojans, privilege extension, resource stealing).The network area introduced security threats from networking (credential stealing, sniffing, man-in-the-middle) and distributed computing (sybil attack, censorship, tracking). The Internet model added DOS, stolen identities and viruses. Combinations of threat models brought us DDOS and a wave of social-engineering threats. User conceptual models (phishing, klez) and bespoke (badly designed and implemented, custom made) applications turned out to be the weakest links in the whole chain. Nowadays a software project should no longer assume a single threat model.
phising (credential attacks through social engineering) certificate confusion Example: Web Threat Model authorization errows input /output validation errors web-trojans sesson takeover SQl injection server value change Browser bugs credential attacks (cookie/sessionID stealiing) virus/trojans SSL Cipher Specs buffer overruns authentication problems maintenance problems (e-mail to customers etc.) cross-site-scripting A good threat model is the basis for security related design patterns which can be pre-implemented in the architecture of web-development frameworks. A threat model requires understanding of the technologies used: http, html, SSL, SQL etc.
Phishing A typical fake-email attack (phising) which tries to extract user credentials. The real link was to http://deutsche-bnk.info/ shown in the browser bottom line. Interestingly, Deutsche Bank detected this case quickly and changed the image behind the embedded image reference to a warning message.
Why does SSL not help? SSL does not prevent secure connections to unintended partners. Are the credentials stolen from the users PC? No, but this could happen as well, e.g. through a web trojan while logged in at the server. Would a challenge/response authentication model help? No Would a better browser help? Possibly. Could show the link better. Could handle the critical step of verifying the NAME/HOST in a server certificate MUCH better. Is it a HTML problem? In a way yes: look at the design of the <a> tag if the real „href“ attribute matters (as in this case) Short Analysis of Phishing This short analysis shows that a pure host or network based threat model does not capture the problems behind phishing. What we need is a mutual authentication between customer and bank without a chance for the customer to mistakenly confuse identities.
phising (credential attacks through social engineering) certificate confusion A Possible Solution attacks on credentials are useless software secure channel between customer and bank Card-Reader with display and PIN protection for client credentials. Includes bank certificate this architecture allows secure connection establishment. If a user clicks on a fake link the bank specific smart card and the embedded reader software would not allow a connection to be established. But on top of this it would also allow every client action to be signed by the client. This creates non-repudiation.
Channel based vs. object (message) based Centralized vs. de-centralized Usability vs. Security Identity vs. capability Crypto-protocol vs. it-procedure Some Dimensions of Security After dealing with several different security problems these categories emerged. To me, they organize the whole area of security and represent different approaches. The following examples will demonstrate some of those dimensions. There are probably many more.
Root CA must be trusted Client needs to match „name“ from server certificate with the intended partner association is end-to-end. Intermediates can only forward packages Data are safe only during transport (no non-repudiation) Security not as powerful as in the case of object based security (signatures etc.) Channel Based Security:SSL Client Certificate Root CA Certificate private key Server Certificate Cipherspecs Security Association (end-to-end) Client Endpoint (Web Service) encrpyted data data data SSL is not the silver bullet. Again, usability problems are the biggest issue: Clients confusing names (there is NO global naming directory), servers forgetting to set proper cipherspecs. Both partners involved need to put complete trust into the root CA.
Data are transported in a store-and-forward manner At every intermediate a secure channel ends. The data (objects) need to carry the security information with themselves. Intermediates can manipulate objects but the objects can be protected as well (signature) Object Based Security: Web Services Credentials Credentials encrypted data encrypted data Intermediate (Web Service) data data Signature Signature Credentials Credentials Security Association (end-to-end) Client Endpoint (Web Service) Object based security allows new business models (e.g. automated supply chain management through intermediates) because messages can be kept safe across different channels.
Special Case: Single-Sign-On (SSO) trusted third party Security Token Issuer trust relationship Request for access token (together with credentials that proof identity) offline token verification. Optional online check Access token with message Client Endpoint (Web Service) optional liveness check This is the „canonical“ architecture of a SSO system. It is based on the concept of a trusted third party: all services which accept tokens put their trust in the security token issuer that proper authentication checks where performed. The big advantage vor the services lies in the fact that they do no longer need an expensive authentication infrastructure.
Portal Single-Sign-On (SSO) trusted third party Security Token Issuer trust relationship offline token verification. Optional online check authentication check SSL Session ID Client reverse proxy Application Server Application Server Application Server cookie Company portals are of course using their own issuer (located in the trusted computing base of a DMZ) to check authentication. Applications do NOT check authentication. They rely on the token as proof of successful authentication. The token itself can contain authorization information as well (good for the performance of distributed systems). No application server state is stored on the client – the SSL session id is used to map e.g a state cookie to a user session. A good description can be found in the latest IBM redbook on portal security (www.redbooks.ibm.com)
Federated Single-Sign-On trusted third party Security Token Issuer A Security Token Issuer B trust relationship Request for access token (together with credentials that proof identity) trust relationship Access token with message offline token verification. Optional online check Client Endpoint (Web Service) optional liveness check Federated means that there is no single Security Token Issuer. Imagine the data such a central system would collect over the time (e.g. MS Passport). Businesses are not interested in creating such a system. An additional benefit of federation lies in support for different security infrastructures (PKI, Kerberos) which would normally prohibit communication.
Web Based Single-Sign-On (SSO) 5. STI creates token signed with private key. trusted third party 8. Service does offline token verification (via public key of STI). Optional online check. Sets cookie Security Token Issuer 3. STI requests authentication 4. Client sends credentials 6. STI redirects client back to service and attaches token trust relationship 2. redirect to token issuer (return address attached) Client Endpoint (Web Service) 1. service request (not authenticated) 7. client repeats request, this time with token Technically web based SSO is using http redirects, GET parameters and signed tokens. Of course all connections need to be secure. A critical point is that the token always travels through the client (browser) where it can be attacked. Single-Log-out is also critical. More information can be found at the liberty alliance project. (see ressources)
Message authentication: who is the author of a message, who is the SENDER of a message (replay attacks) Tokens used as keys can be lost and used by somebody else Secrets can leak when used for authentication „Liveness“ of tokens: is an authorization or authentication token still valid? Token revocation Standardization of security related information: who can understand which crypto-methods? How are attributes/authorizations expressed? Typical Problems of Object Based Security I expect a push for object based security in the future. Web service business models, smart card systems etc. all allow or require signed/encrypted messages. Distributed systems (p2p) are ideally suited for message based security.
Trusted Third Parties for SSO– a good concept? CA trust relationship offline token verification. Optional online check software client request, signed Endpoint (Web Service) optional liveness check Card-Reader with display and PIN protection for client credentials. Includes service certificate A card based SSO system would be much better from a privacy point of view. It would also reduce token problems (lost, stolen etc.).
central authority creates single-point of failure. big privacy issues secure backup and professional maintenance storage of large amounts of data Introduction of numbering systems (not constitutional) Centralized vs. Decentralized Security Mechanisms • Data under user control • Users private key needed to decrypt data • Lost smartcard problem • Reader Problem • Size problems • PIN problems • Card infrastructure expensive to build (e.g. card issuing based on what?) there is no real silver bullet. Let‘s discuss the trade-offs in the german job and health card approaches
Job Card: The Problem Space This diagram is taken from Christiane Schultzki-Haddouti (see resources). It shows the current data flows and media conversion problems. The architecture is a star with the employeers responsible for the employee data. The employer gets requests for everything to do with employment (social security, unemployment etc.). Please note: Using channel based security most of these flows could be made secure and automated. But this raises privacy concerns of course.
Job Card: Architecture This diagram is taken from Christiane Schultzki-Haddouti (see resources). Looking at the data flows the architecture is basically a publish-subscribe system with a central storage. The system separates data storage and authorization to get data. Whoever needs employee data needs the employee to sign a token with her private key. The requester then sends the token together with the request to the central storage. The central storage validates the request (using the token) and returns employee data.
Employee data are encrypted with key from central storage facility The central storage facility stores all employee related data. Employees have a smart card with a key for digital signatures. They sign requests for their data and thereby authorize the request. Data requestors are equipped with card readers that allow employees to insert their cards and sign requests. Job Card Security Design Smart cards usually carry several keys for different purposes. Public keys for digital signatures, encryption/decryption and authentication are popular. But also symmetric keys can be stored. Access is typically secured through a PIN based system. An unsolved problem for both job card and health card is who will be the issuer of those cards. The issuer needs to verify identity (costly) and e.g. bank would like to re-use their existing authentication data instead of performing a new identification/authentication procedure.
Job Card: Security and Politics The red line marks both a technical and a trust border. Technically it marks where the power of the employees key ends: the employee data are stored using a storage facility key not the employee key. This forces the employee to put trust in a) the storage facility to not accept non-validated requests and b) the trust center to not falsely identify employees. If the employee data would be encrypted with the employees encryption key, trust would not be necessary. (but other things like key escrow etc.). In the current design it depends on POLITICS only how safe the employee data really are as the whole authorization system could be cut off without affecting technical operations. Not to forget: a publish-subscribe architecture allows new data sinks any time...
Health System Diagram drug eceipts, medical statements, first and second level treatment prepare and accept medical statements emergency vehicles doctors hospitals equipment and emergency data billing information drug receipts health insurances pharmacies patients health prof. organizations health portals billing, payments standards for drugs and treatment The german health system is characterized by many and complex relations between all participants. Important legal constraints are a) free choice of hospital, doctor etc. for patients and b) the right to privacy for most health related data. Loss of privacy could lead to major problems for patients e.g. if they are diagnosed with a critical illness.
reduce paper based workflows of drug receipts and medical statements offer live saving information (e.g. to emergency units) create a file with all health related data of a patient, thereby improving medical services and control Allow patients strict control over what information they are willing to give to other persons. Replace the read-only current health-card which needs to be replaced when patient data (insurance, name) change. Save money through faster processing Allow better control over medical treatments through the use of qualified signatures from medical personnel (health professional card) Prevent abuse of health insurance through people sharing cards. Goals for the health card Already the list of requirements is highly political: does it include shorter workflows (e.g. by directly connecting doctors to insurences – cutting out the professional organizations?). And it is a nice example that complex security designs need an excellent understanding of the social and organizational context. See Warda et.al. in resources.
qualified signature for patients public part with emergency info access controlled private part. Needs authorization through patient. PIN protection Limited Size. Enough to hold public keys and certificates No certificate check against health professional certificates Possibly multi-function card which carries other applications No reader defined yet. Patients not expected to have reader Technical aspects of the health card Getting private data from the card will require a health professional certificate. Access control is an open issue: What is the proper granularity? A complete medical statement? Parts of it – with the danger that doctors will not notice something critical? How do you prove that a doctor has received the proper information? What if a patient is too sick to go to the pharmacy with her card? (Delegation problem)
Alternatives for Patient Data Storage health card picture and name Central Storage via network The healthcard alone is too small e.g. for large numbers of x-ray images. Also the problem of card loss is critical. Therefore a hybrid solution is considered: some data stored directly on the card and some data stored on the network with the patients card holding symmetric keys to the data. Patient data have a problem with asymmetric keys: since patients are entitled to freely select medical treatment (at least in theory) a doctors office cannot encrypt a medical statement in advance using a public key mechanism – the receivers public key is not known yet.
Why the card reader is important secure channel between customer and bank attacks on credentials are useless Internet Pharmacy confirmation software order digitally signed receipt for drug checks signature and confirms A proper drug order should update the health card with a confirmation signature from the pharmacy. This would also allow faster reimbursement for the patient. The internet pharmacy would therefore need a health professional certificate (could be a problem with international pharmacies) and the patient would need a reader. Currently the health card system plans readers in pharmacies, doctors offices etc.
Transparency and control of medical treatments „ There are things we don‘t even tell our wifes...“ • A campaign by the dentists professional organization against the health card: • patient data are best kept at the doctors office • partial data from a health card are dangerous • neither patients nor doctors should be transparent Control over data is the base requirement for legal actions in case a treatment did not work. Once medical statements are signed and stored under the patients control doctors will be made responsible for treatments. The case above shows how fierce opposition against some aspects of the health card will be. Here dentists try to confuse the need for transparency of medical treatment with the patients right to privacy.
Does it make sense to use SSL with e-mail? Which has more risks: EC-card or credit card? For whom? Your company uses a fingerprint based authentication system. How does this affect your security as an employee? What is the biggest problem of passwords? A digital signature proves what? Questions Before we go after usability and security as well as Identity vs. Capabilities a few questions to check for security awareness (;-)
Usability vs. Security: some guidelines Path of Least Resistance. The most natural way to do any task should alsobe the most secure way. Appropriate Boundaries. The interface should expose, and the system shouldenforce, distinctions between objects and between actions along boundaries thatmatter to the user. Explicit Authorization. A user's authorities must only be provided to otheractors as a result of an explicit user action that is understood to imply granting. Visibility. The interface should allow the user to easily review any activeactors and authority relationships that would aect security-relevant decisions. Revocability. The interface should allow the user to easily revoke authoritiesthat the user has granted, wherever revocation is possible.to express security policies in terms that t their goals. Clarity. The effect of any security-relevant action must be clearly apparentto the user before the action is taken. Expected Ability. The interface must not give the user the impression that itis possible to do something that cannot actually be done. Trusted Path. The interface must provide an unspoofable and faithful com-munication channel between the user and any entity trusted to manipulateauthorities on the user's behalf. Identifiability. The interface should enforce that distinct objects and distinctactions have unspoofably identiable and distinguishable representations. Expressiveness. he interface should provide enough expressive power (a) todescribe a safe security policy without undue diffculty; and (b) to allow usersto express security policies in terms that t their goals. Taken from Ka-Ping Yee, see Resources. Looks like nowadays the only ones to follow this advice are the dialer companies. Compare the red sections with the behavior of a browser and an associated dialer dialog.
Dialers and Usability Explicit Authorization. A user's authorities must only be provided to otheractors as a result of an explicit user action that is understood to imply granting. URL line: to be manipulated by downloaded pages OK is preset. In some cases applet or script will AUTOMATICALLY send filled in page to dialer previous dialogs made the user type in OK frequently as the default and reasonable behavior. Now the semantics of default suddenly change. OK Type in OK in this field: Path of Least Resistance. The most natural way to do any task should alsobe the most secure way cancel button does not work some small printed stuff that user accepts everything. cancel Trusted Path. The interface must provide an unspoofable and faithful com-munication channel between the user and any entity trusted to manipulateauthorities on the user's behalf. Status line: to be manipulated by downloaded pages Dialer companies carefully craft their dialogs and they rely on common practices from other programs (e.g. to make the non-critical action a default or to use OK for harmless diaglogs). The browser violates several principles of secure delegation. At least some of the browser problems are related to the problem of identity vs. capability (ACL vs. Keys). See the DARPA Browser evaluation for more
Identity vs. Capability or „will we ever get rid of viruses and trojans?“ 3. User starts program. OS checks whether user has proper role/right by selecting from ALL rights of the user. 2. System creates subject and assigns privileges 1. login establishes identity software 4. Program runs with all rights from user This is the way Access Control Lists work. ACLs are used by most operating systems. The full delegation of user rights to programs allows viruses and trojans to be so effective. With capabilities a subset of rights can be handed over to a program which e.g. does not allow the program to „call home“. Think about it from the perspective of trust: simply by knowing how somebody is one should not put all trust into the persons actions. See: www.erights.org for much more information. Note that the program does NOT consider Identity for the decision to perform some action. This is also an important issue for privacy protection.
Cryptographic vs. Procedural Verification • black-box system with special hardware. No paper trail, no receipt. (Diebold voting machines). Security relies on tested releases and closed hardware. • black-box system with paper trail. Selected precincts are counted in case of close votes or just randomly selected • Open source e-voting system. Security is believed to come from source code inspections by many people • Black-box system with voting receipt (allows voter to control election through public web site with her vote) • Black-box system with voting receipt. Voters can control their vote AND whether it was counted properly. Danger of vote buying. The differences between those approaches are in where they put trust. Diebold requires the voter to put trust in the systems based on procedural verification only. Voters have no chance for external verification. At the other end of the spectrum are systems that use cryptography (blind signatures, homomorphic encryption) to achieve verification. This gives voters the chance for end-to-end control and makes the system itself rather unimportant. See more: www.verifiedvoting.org
Political Aspects of Security • The drive for authentication – a helpful concept? • Location based services – when authorization should be enough • Human nature, security measures and political goals. Almost 20 years ago the german magazine „Spiegel“ had a series on data processing and its social dangers. „Das Stahlnetz stülpt sich über uns“. For many years the success of personal computing and later the Internet have made those questions seem rather unimportant. Government actions after 9/11 are forcing us to watch closely over our rights to privacy, anonymity etc.
Biometrics at airports – preventing suicide attacks? to airplane Body checks Baggage checks Regular Entrance DB with iris scans and authentication data Iris Scan Entrance to airplane Is it a good idea to create a fast boarding entrance for passengers which have themselves registered in an iris scan DB? Is authentication enough to make flights secure? Did authentication fail on 9/11? Authorities like the concept of authentication because it is based the fact that once an authority knows the identity of a person that person can get PUNISHED. This idea obviously fails in the case of suicide attacks. And for the fast boarding entrance: now suicide attackers need frequent flyer programs to skip further controls...
Access Control – authentication needed? location based services Toll systems Ticket systems It is important to realize that authentication is NOT neccessary for access control. It is only convenient for authorities to always start with authentication but capability based systems are a proof of concept for access control without identity check. The drive for authentication becomes very visible in the case of the card based mobile phone. There is no technical reason at all to force buyers to expose their identity – the phone calls are prepaid. But now even Switzerland seems to require buyer authentication.
Humans and Security • How risks are percieved depends on how spectacular the threats are, not how likely • A tendency to see only the good side of security measures taken. Counterproductive side-effects etc. are not realized. • Believe in security measures replaces effectivity measurements • A tendency to give up rights for better security • A tentency to direct security measures against the symptoms of a problem and not the root cause. Security measures can be harmless but ineffective, annoyances or outright dangerous. Security measures work on severals levels: they can decrease real risk but are also PR mechanisms and political statements
Examples • „Feel good security“: • Placing military at train stations for some time after a terrorist attack. • Send military jets over a big city after a bombing • Put X-Ray machine in lobby • Annoyances: • Simulate weapon searches at tourist places • Dangerous Security: • creating information bases on the whole population (see heise news in resources) • Ask people to report „suspicious“ neighbours • Announce „threat levels“ to terrorize population Security measures can be harmless but ineffective, annoyances or outright dangerous
Beyond Fear: Challenge Security What are the assets that you want to protect? What are the risks to those assets? How well does the security solution mitigate those risks? What other risks are caused by the security solution? What costs and trade-offs does the security solution impose? Taken from Bruce Schneiers book „Beyond Fear“. I would like to add one more: Are there alternative solutions which do not have those counter-productive effects?
Sverre H. Huseby, Innocent Code – A security wake-up call for Web Programmers (in german by dpunkt). Exzellent resource on input validation, SQL injection etc. Bruce Schneier, Beyond Fear – shows how security can be used to restrict rights. On stupid and dangerous security. Raises questions like: does security measure X really make things more secure? What are the side-effects? Get his newsletter „cryptogram“. Kevin Mitnick, The Art of Deception. Mostly telephone based attacks on trust based behavior. Nice cases. Shows how to play the language games needed for deception. Shows also how critical trust-establishment really is. Dirk Heringhaus on OBSOC. http://ds.ccc.de/083/obsoc/ Describes the security problems found in the t-com contract and partern web application. Liberty Alliance Homepage: http://www.projectliberty.org/ Describes web based SSO. You should also read the SAML docs from www.open-group.org for possible threats in such a system. Resources (1) More resources can be found on www.kriha.org
Christiane Schultzki-Haddouti, The german job-card. http://www.heise.de/ct/04/13/046/ Good architecture diagrams. DIMDI resources on the health card (including the book on telematics in the health industry) http://www.dimdi.de/de/ehealth/karte/index.htm Dr. Frank Warda und Dr. Guido Noelle, Telemedizin und eHealth in Deutschland: Materialien und Empfehlungen für eine nationale Telematikplattform (free download via dimdi) Prozahn-Datenschutz, dentist campaign against the health card: http://www.prozahn.de/datenschutz On usability and security: User Interaction Design for Secure Systems, Ka-Ping Yeehttp://zesty.ca/sid/ Very good guidelines for secure designs. Watch how close some of them are to the ideas from capability groups.. A capability based browser: http://www.combex.com/papers/darpa-report/darpaBrowserFinalReport.pdf Understand the problems of unrestricted delegation of rights. U Using Microsoft Technology to Create Next Generation OSS-BSS Infrastructure, www.ccc.de/datenschleuder Resources (2) More resources can be found on www.kriha.org
New european initiatives to collect ALL traffic date (telecomunication, internet etc.) without restrictions (probable cause, persons etc.) (http://www.heise.de/newsticker/meldung/50940 Resources (3) More resources can be found on www.kriha.org
