dimensions of security

Dimensions of Security

Mechanisms, Architectures and Politics

Walter Kriha, Hochschule der Medien Stuttgart

Agenda

• 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)

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.

Goals

• 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

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

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!

customers

application server

admins

web server application server

InternetInternet

Partner Services

Test machines

OBSOC infrastructure

OBSOC Security Problems

1. Changing URLs allowed to work around authentication and authorization (no client data validation)

2. Password handling for customers and admins was way below standard and allowed easy password guessing (wrong protocol, weak procedures)

3. Customers and Admins used the same entrance with the same low level security (wrong design)

4. Implementors of OBSOC held critical data, e.g. SQL-Server backups on private domains, including domain passwords. (Developers lacking basic security principles)

5. It was possible to break through from web application space into windows domain space.(Infrastructure unsafe)

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.

from D.Heringhaus (see resources). ConPK=vvv would change to a different user contract

OBSOC Security as a System

Security is the result of a multi-dimensional effort. OBSOC failed in all three dimensions.

Protocol Implementation Procedure

Wrong authentication protocol for admins

Lack of access control

Weak password handling

No filters

No clean software architecture

No security Sign-Off

No security standards and procedures

No incident response in place

Basic Mistakes and Advanced Frameworks

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

Mistakes .NET Platform

•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

-Web services

- legacy integration

-transaction enabled

-XML support

-High availability

-ASP+

Security by Framework

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.

Security features provided Problem areas

•Support for sessions

•separate authentication

•authorization interfaces

•infrastructure integration

•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

Explanations

• 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.

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.

Security as an Awareness Problem

• Cryptographic Algorithms

• Security Protocols and Mechanisms

• Security Policies/Principles

• Frameworks

• Domain Problems (e.g. web)

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.

web application?

Threat Models

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.

User conceptual model

host security client side

host security server side

bespoke applications

network/internet threats

peer-to-peer model

Example: Web Threat Model

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.

phising (credential attacks through social engineering)

certificate confusion

Browser bugs

credential attacks (cookie/sessionID stealiing)

virus/trojans

SSL Cipher Specs

buffer overruns

authentication problems

maintenance problems (e-mail to customers etc.)

authorization errows

input /output validation errors

SQl injection

server value change

web-trojans

sesson takeover

cross-site-scripting

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.

Short Analysis of Phishing

• 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)

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.

A Possible Solution

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.

phising (credential attacks through social engineering)

certificate confusion

Card-Reader with display and PIN protection for client credentials. Includes bank certificate

attacks on credentials are useless

secure channel between customer and banksoftware

Some Dimensions of Security

• Channel based vs. object (message) based• Centralized vs. de-centralized• Usability vs. Security• Identity vs. capability• Crypto-protocol vs. it-procedure

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.

Channel Based Security:SSL

• 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.)

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.

ClientEndpoint

(Web Service)

Security Association (end-to-end)

Client Certificate

Root CA Certificate

private key

Server Certificate

Cipherspecs

encrpyted data

data data

Object Based Security: Web Services

• 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 allows new business models (e.g. automated supply chain management through intermediates) because messages can be kept safe across different channels.

Client

Intermediate(Web Service)

Security Association (end-to-end)

Credentials Credentials

data

Signature

Credentials

encrypteddata

Endpoint(Web Service)

data

Signature

Credentials

encrypteddata

Special Case: Single-Sign-On (SSO)

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.

ClientEndpoint

(Web Service)

Access token with message

Security TokenIssuer

Request for access token (together with credentials that proof identity)

trusted third party

trust relationship

optional liveness check

offline token verification. Optional online check

Portal Single-Sign-On (SSO)

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)

Clientreverse proxy

SSL Session ID

Security TokenIssuer

trusted third party

trust relationship


Application Server

authentication check

Application ServerApplication

Servercookie

Federated Single-Sign-On

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.

ClientEndpoint

(Web Service)

Access token with message

Security Token

Issuer A

Request for access token (together with credentials that proof identity)

trusted third party

trust relationship



Security Token

Issuer Btrust relationship

Web Based Single-Sign-On (SSO)

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)

ClientEndpoint

(Web Service)

1. service request (not authenticated)

Security TokenIssuer3. STI requests

authentication

4. Client sends credentials

6. STI redirects client back to service and attaches token

trusted third party

trust relationship

2. redirect to token issuer (return address attached)

8. Service does offline token verification (via public key of STI). Optional online check. Sets cookie

5. STI creates token signed with private key.

7. client repeats request, this time with token

Typical Problems of Object Based Security

• 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?

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?

A card based SSO system would be much better from a privacy point of view. It would also reduce token problems (lost, stolen etc.).

Endpoint(Web Service)

client request, signed

trust relationship



Card-Reader with display and PIN protection for client credentials. Includes service certificate

software

CA

Centralized vs. Decentralized Security Mechanisms

• 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)

there is no real silver bullet. Let‘s discuss the trade-offs in the german job and health card approaches

• 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?)

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.

Job Card Security Design

• 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.

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

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.

doctors

pharmacies

emergencyvehicles

patients

health portals

hospitals

health prof.organizations

drug eceipts, medical statements, first and second level treatment

health insurances

billing information

standards for drugs and treatment

billing, payments

prepare and accept medical statements

equipment and emergency data

drug receipts

Goals for the health card

• 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.

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.

Technical aspects of the health card

• 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

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

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.

health cardpicture and

name

Central Storagevia network

Why the card reader is important

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.

Internet Pharmacy

attacks on credentials are useless

secure channel between customer and bank

software

digitally signed receipt for drug

checks signature and confirms

order

confirmation

Transparency and control of medical treatments

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.

„ 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

Questions

• 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?

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

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.

Path of Least Resistance. The most natural way to do any task should also be the most secure way.

Appropriate Boundaries. The interface should expose, and the system should enforce, distinctions between objects and between actions along boundaries that matter to the user.

Explicit Authorization. A user's authorities must only be provided to other actors 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 active actors and authority relationships that would aect security-relevant decisions.

Revocability. The interface should allow the user to easily revoke authorities that 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 apparent to the user before the action is taken.

Expected Ability. The interface must not give the user the impression that it is 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 manipulate authorities on the user's behalf.

Identifiability. The interface should enforce that distinct objects and distinct actions have unspoofably identiable and distinguishable representations.

Expressiveness. he interface should provide enough expressive power (a) to describe a safe security policy without undue diffculty; and (b) to allow users to express security policies in terms that t their goals.

Dialers and Usability

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

Status line: to be manipulated by downloaded pages

URL line: to be manipulated by downloaded pages

OK

cancel

Type in OK in this field:

some small printed stuff that user accepts everything.

cancel button does not work

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.

Path of Least Resistance. The most natural way to do any task should also be the most secure way

Explicit Authorization. A user's authorities must only be provided to other actors as a result of an explicit user action that is understood to imply granting.

Trusted Path. The interface must provide an unspoofable and faithful com-munication channel between the user and any entity trusted to manipulate authorities on the user's behalf.

Identity vs. Capability or „will we ever get rid of viruses and trojans?“

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.

2. System creates subject and assigns privileges

software

1. login establishes identity

3. User starts program. OS checks whether user has proper role/right by selecting from ALL rights of the user.

4. Program runs with all rights from user

Cryptographic vs. Procedural Verification

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

-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.

Political Aspects of Security

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.

• The drive for authentication – a helpful concept?

• Location based services – when authorization should be enough

• Human nature, security measures and political goals.

Biometrics at airports – preventing suicide attacks?

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...

Regular Entrance

DB with iris scans and

authenticationdata

Iris Scan Entrance

Baggage checks

Bodychecks

to airplane

to airplane

Access Control – authentication needed?

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.

location based services

Toll systems Ticket systems

Humans and Security

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

• 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.

Examples

Security measures can be harmless but ineffective, annoyances or outright dangerous

„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

Beyond Fear: Challenge Security

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?

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?

Resources (1)• 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.

More resources can be found on www.kriha.org

Resources (2)• 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 Yee http://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 (3)

• New european initiatives to collect ALL traffic date (telecomunication, internet etc.) without restrictions (probable cause, persons etc.) (http://www.heise.de/newsticker/meldung/50940


dimensions of security

Documents