[Impressum]
[E-Mail]
Modeling the German
Electronic Health Card (EGK) (1)
The first step is to describe the components and user of
the application, the communication infrastructure and the attacker
abilities.
- The patient is a user that owns an electronic health card (Gesundheitskarte) and goes to a doctor or in a pharmacy.
- The doctor (Arzt) is a user of the application that has a
smartcard (Heilberufsausweis). In his office he has a terminal, called
Arzt-PC, which has two cardreaders: One for the health card
(Gesundheitskarte) of a patient and one for his Heilberufsausweis.
Moreover, the Arzt-PC is connected to a Service representing the health
insurance company (Krankenkasse). This connection ist used to compare
the patients personal data stored on a health card with the data stored
at the insurance company.
- The
pharmacist (Apotheker) is a user of the application the has a
smartcard (Heilberufsausweis). In his pharmacy he has a terminal,
called Apotheken-PC, which has two card readers: One for the health
card (Gesundheitskarte) of a patient and one for his Heilberufsausweis.
- In some pharmacies a terminal called Kiosk exists. This is some
kind of an automat which is connected with a smartcard reader and can
be used by a patient to read and check the data that is stored on his electronic health card.
The nodes of the deployment diagram show the participants (i.e. user
and components) of the application. The communication paths show which
components communicate with each other. E.g. the patient communicates
with the Arzt-PC to enter his PIN. The communication paths are
annotated with Stereotype <<Threat>>
if the attacker is able to interfere the communication of this channel.
In this case study we assume that an attacker has full access (i.e.
read, send and suppress messages) that are exchanged between a
smartcard and a terminal or between a terminal and a service. All other
communication channels, i.e. the ones between the user and the
terminals, are not attacked. They represent the communication of a user
with a terminal, e.g. via a graphical user interface. We assume that no
attacker is standing behind e.g. a doctor in a doctor's office and
reading the data that the doctor is entering into its PC.
Back, Next Step: Class Diagrams of the application
