Michael Huber, Ali Sunyaev and Helmut Krcmar
Chair for Information Systems, Technische Universit
at M
unchen, Germany
Security analysis, Health Care Telematics, Electronic Health Card, Information Security Management Sys-
Based on ISO 27001 for Information Security Management Systems, this paper introduces a newly developed
security analysis approach, suitable for technical security analyses in general. This approach is used for a
security analysis of several components and processes of the Health Care Telematics in Germany. Besides the
results of the analysis, basics for further analysis and verification activities is given.
In Germany, the Electronic Health Card (eHC) will
replace the present health card as requested by law.
By establishing the eHC, several improvements, such
as cost savings, better ways of communication in the
health care sector or the self-determination of the in-
sured person concerning medical data, are supposed
to be achieved (Schabetsberger et al., 2006).
The use of IT to administrate medical data of the
insured, implicates the question, whether these sys-
tems are safe enough to satisfy requirements like pri-
vacy, safety, security and availability (Heeks, 2006).
The data administrated by the eHC and its infras-
tructure is mosltly strictly confidential as it contains
personal information about peoples state of health,
course of disease and hereditary diseases (Lorence
and Churchill, 2005). As for example insurance com-
panies or employers would be highly interested in
such information, the security measures of TI systems
dealing with them have to be analysed in detail (An-
derson, 2001).
Due to their ethical, judicial and social implica-
tions, medical information requires extremely sensi-
tive handling. These aspects emphasise the need for a
security method that evaluates the technical aspects of
information security in a health environment. In this
paper, we first introduce the health telematics infras-
tructure. After the introduction, an analysis approach
based on ISO 27001 is introduced in chapter 3. The
result of its application to several components of the
health telematics infrastructure is presented in chap-
ter 4. Chapter 5 concludes the paper and provides an
outlook. The current security status of health care in
Germany was evaluated and valuable hints for future
developments in the health care sector could be de-
The paper is based on a literature review (e.g.
Computers & Security, Information Management &
Computer Security, Information Systems Security, In-
ternational Journal of Medical Informatics, Informa-
tion Systems Journal, European Journal of Informa-
tion Systems, International Journal of Information Se-
curity, security & privacy, Journal of computer secu-
rity, ACM Transaction on Information and Systems
Security und ACM Computing Surveys). The secu-
rity analysis approach presented in this paper differs
from other approaches due to the following aspects:
Focus (health care sector; technical evaluation of se-
curity measures), being up-to-date (appliance of up-
to-date techniques and standards) and regional dis-
tinctions (located in germany, regional and political
The present health card in Germany is a storage-only
smart card, whereas the eHC will provide a micro-
processor enabling services such as the ciphering or
signing of information (Schweiger et al., 2007). This
insurance card is actually used exclusively for admin-
istrative purposes such as identifying the insured per-
son or accessing administrative data stored on the card
Huber M., Sunyaev A. and Krcmar H. (2008).
In Proceedings of the Tenth International Conference on Enterprise Information Systems - ISAS, pages 144-153
DOI: 10.5220/0001684901440153
Figure 1: Schematic representation of the Health Telematics Infrastructure.
for accounting purposes.
Besides the eHC, there are also smart cards for
health personnel, medics, chemists and various other
professional categories, which need to interact with
the eHC and its related infrastructure (these cards are
called Health Professional Cards, shortened HPC).
The eHC as a smart card is only one part of the
infrastructure required to implement the functionality
demanded by law. The major part is represented by
an IT system called Health Telematics Infrastructure
(HTI) and its associated processes, both described in
the following sections.
The given introduction has to be considered as a
brief description of the major parts, functions and pro-
cesses of the HTI. For a more detailed description,
we refer to the public development documents by the
Gematik mbH which can be found at the organisa-
tion’s website
. Furthermore, a compact introduction
to the eHC can be found in (Huber et al., 2008).
2.1 Functions and Stages of Expansion
The eHC and its associated infrastructure will be in-
troduced in several steps with a growing amount of
functionality and complexity. For the insured, the us-
age of some of the functionalities introduced by these
steps is mandatory, the use of some other optional
(Haux, 2005).
The first step of introduction will provide the eHC
as a smart card with the ability to store the patients
administrative data (for instance name, address, date
of birth, insurance information, etc.). On its backside,
the eHC provides a form, which enables the card to
act as an europe-wide standardised health card. The
acceptance of this step is mandatory for the insured.
The second step introduces the functionality to
store prescriptions on the smart card, formally pro-
vided to the insured as a paper form. This step is
mandatory for the insured as well.
Regarding the remaining steps three and four, the
use of their functionality is optional. For these steps,
it is planned to provide things like emergency-data,
the documentation of the history of medication and
an electronic dossier of the insured, partially stored
on the smart card, partially provided by a centralised
data processing center as part of the HTI.
2.2 Architecture
Figure 1 outlines the architecture of the HTI, which is
divided into a central and a decentral part.
The central part consists of several services, which
can be accessed by the insured and the service
providers such as medics or hospitals. These services
will be located and administrated in one or more cen-
tral computing centres.
The decentral part of the HTI is located at the
medical service providers. This part consists of the
medical service provider’s LAN, the Connector, card
readers for eHC and HPC and the smart cards them-
selves. The connection between decentral and central
part of the HTI is established by using a vpn connec-
tion over the internet, initialised by the medical ser-
vice provider’s Connector and accepted by a vpn con-
centrator located at the central part of the HTI.
Not part of either fraction of the HTI are the so
called Primary Systems. These systems are software
products, medical service providers use for storing
their patients’ records, for accounting purposes and
various other tasks related to health care. Because
of those components are being developed and main-
tained by third party companies, security aspects can
not be supervised by governance and thus, they are
by definition not part of the HTI. Nevertheless, these
systems were considered in the security analysis from
a general point of view, because they do store and ad-
minister sensitive medical data.
According to (Gollmann, 2006), a technical security
analysis is defined as a methodical, traceable analy-
sis of an IT system concerning primarily its technical
Planning to perform a security analysis, it is advis-
able to base the used procedure on established stan-
dards and best practice approaches, so the analysis
relies on a previously approved scaffold.
Regarding security analyses, there are many dif-
ferent solutions from activity catalogues to loose col-
lections of analysis techniques and useful tools. De-
spite of each solution having its advantage in its ded-
icated domain, no appropriate standard or proceed-
ing could be found to analyse the mentioned compo-
nents in the way, the definition of (Gollmann, 2006)
demands. Therefore, a new approach had to be de-
veloped, allowing to analyse the relating components
from a technical point of view, using tools, methods
and processes in a structured and traceable way.
Figure 2: Levels of an Information Security Management
3.1 Information Security Management
Although a new approach had to be developed, there
are some standards which were used as its base. These
standards apply to Information Security Management
Systems (ISMS). These systems are used to implement
and maintain IT security in organisations by coordi-
nating various activities, processes and tools.
An ISMS contains two levels, a System-level and
a Process-level as shown in figure 2. According to
(BSI, Bundesamt f
ur Sicherheit in der Information-
stechnik, 2004), the Process-level contains several
subprocesses such as development, planning, imple-
mentation, evaluation, and maintenance of IT secu-
rity. The System-level in contrast is concerned with
the orchestration of the Process-level’s tasks. It con-
tains matters like organisational structure, responsi-
bilities, processes and resources.
3.2 ISO 2700x
Besides well known standards like the BSI IT-
, BS 7799-2 (BSI, British Standards In-
stitution, 1999) or COBIT (ITGI, IT Governance In-
stitute, 2007), there is a relatively new group of stan-
dards dealing with ISMS. This assembly of standards
is called the ISO/IEC 2700x family and will contain
at least seven standards. At the moment (november
2007), some standards of the 2700x family are already
published, others are still under development.
ISO 2700x contains, respectively will contain
standards for establishing and maintaining IT secu-
rity. Therefore, it combines particular standards from
simple vocabulary via ISMS requirements, risk man-
agement and management activities up to practical
implementation guidelines. Thus, this family is or
will be one of the most complete and comprehen-
sive up-to-date compilations of standards regarding
the ISMS issue.
3.3 The Plan-Do-Check-Act Approach
of ISO 27001
One of the most important standards of the ISO 2700x
family is the 27001 standard, which actually emerged
from the British Standard 7799-2 (BSI, British Stan-
dards Institution, 1999). In this standard, fundamental
processes to plan, establish, operate and maintain in-
formation security in organisations are described. The
main scaffold to achieve these goals is represented
by the Plan-Do-Check-Act approach (PDCA). This
approach, as shown in figure 4, contains four steps,
which are executed repeatedly.
In the first step of PDCA, an ISMS policy has to
be established. Therefore, objectives, processes and
procedures which are essential for managing risk and
improving information security have to be set up in
accordance with an organisation’s objectives and poli-
Figure 4: The Plan-Do-Check-Act approach (PDCA).
ICEIS 2008 - International Conference on Enterprise Information Systems
Figure 3: The developed security analysis approach.
In a second step, the ISMS policy has to be im-
plemented and operated. Therefore, the controls, pro-
cesses and procedures set up in step one have to be
The third step measures the effectiveness and per-
formance of the ISMS. The measurement results are
reported to the management for review.
During the fourth step, corrective and preventive
actions based on the results of step three and the re-
view of further relevant information have to be taken.
3.4 From PDCA to Security Analysis
Based on the PDCA model, we developed a new ap-
proach for a technical security analysis. By building
a new approach based on this model, various activi-
ties during a security analysis can be orchestrated in
a reasonable manner. Furthermore, the repeated exe-
cution of the approach’s steps provides a continuous
feedback of the analysis results to accommodate the
analysis activities. Figure 3 outlines the developed
security approach.
The steps of the PDCA approach described in 3.3
are adopted as a scaffold to be filled with analysis
tasks of the developed approach.
The first step of the approach contains the iden-
tification of possible attackers and attack types. The
result of this step will be used later on to design pos-
sible attacks on the IT system. For achieving these
results, statistics, common classification schemes and
other resources can be used. Thus, the first step of the
approach is quite analogue to the first step of PDCA
where an analysis of possible threats takes place.
In the second step of the approach, the assets
of the IT system, security and also legal require-
ments and finally security measures are being iden-
tified. This step goes par with actions of the plan and
do steps of the PDCA approach. There, assets, re-
quirements and measures are identified as well. The
sources for the accomplishment of step two can be
documents of the IT system’s legal basis, results from
a former risk analysis or just basic objectives of IT
security in general.
The third and fourth step are both the central steps,
where analysis activities actually take place. Step
four contains activities of a theoretical character. This
could be for example an Attack-Tree Analysis (cp.
4.4.5) or the application of proper metrics to measure
security. The fourth step in contrast contains analy-
sis activities in a practical way. This could include
for example penetration tests, the use of one or more
exploitation frameworks or the use of individual tools
like port scanners, dedicated exploits, brute forcing
tools, etc. These two steps are thus similar to the
check step of the PDCA approach where the ISMS
is being reviewed and tested.
The fifth step implements a synchronisation of the
steps three and four. The results of each step are used
to improve and complete the activities of the com-
plementary step. The synchronisation of these steps
results in a more complete and accurate analysis, as
both, theoretical and practical activities are used and
improve each other. This step has no analogy in the
PDCA approach as it is a combination of two steps,
which have no counterpart in the PDCA approach.
Step six is more or less optional as it just contains
a recapitulation of the former steps results. If these
are already well documented during the preceeding
steps, step six can be skipped.
In step seven, activities are chosen to minimize
the risks implied by the uncovered vulnerabilities and
weaknesses. This step has its counterpart in the act
step of the PDCA approach, where also measures are
implemented to improve the ISMS.
3.5 Mapping the Analysis Approach to
Figure 5 shows the coherence of the PDCA approach
and the developed security analysis approach. Both
are executed repeatedly, and the activities of the anal-
ysis steps overlap with activities of the PDCA ap-
Figure 5: Mapping the developed approach to Plan-Do-
4.1 Components an Documents
Considered in the Analysis
The components considered in the security analysis
are eHC, Connector, Primary Systems, Card Readers
and the processes occurring during their interaction.
For the analysis, only publicly available docu-
ments were regarded. Of course, the analysis would
be more complete, if also internal documents were
considered, but by using only public sources, the se-
curity analysis is based on the same information level,
any invader looking for an opportunity to attack this
IT system is able to access. Furthermore, some in-
ternal development documents were marked as con-
fidential at the point of analysis (november 2006 to
november 2207) and thus could not be considered at
Altogether, the documents (SGB, 2007), (BDSG,
2003), (SigV, 2001), (SigG, 2001), (StGB, 2005),
(Gematik, Gesellschaft f
ur Telematikanwendun-
gen der Gesundheitskarte mbH, 2007), (Gematik,
Gesellschaft f
ur Telematikanwendungen der Gesund-
heitskarte mbH, 2006a), (Gematik, Gesellschaft f
Telematikanwendungen der Gesundheitskarte mbH,
2006b), (Gematik, Gesellschaft f
ur Telematikan-
wendungen der Gesundheitskarte mbH, 2006c),
(Gematik, Gesellschaft f
ur Telematikanwendun-
gen der Gesundheitskarte mbH, 2005b), (Gematik,
Gesellschaft f
ur Telematikanwendungen der Gesund-
heitskarte mbH, 2005a), (Neeb et al., 2004) have been
considered for the analysis.
All Documents were at most dated to june 2007.
4.2 Identification and Classification of
Attackers and Attacks
The identification and classification follows in large
parts the indexing of (Schneier, 2004) and (Gerloni
et al., 2004). The attackers were thereby classified
by the criterions available amount of time, know-how
and available resources. The attacks were divided
into the topics intention (criminal, publicity, etc.), ori-
gin (internal/external) and technical basis (Schneier,
2004). Furthermore, each attacker group and type of
attack was brought into context with the eHC subject.
It emerged, that the biggest threats emanate
from the groups organised crime and cyber-terrorists
which seem to have the major interests and the largest
financial resources.
ICEIS 2008 - International Conference on Enterprise Information Systems
4.3 Identification of Assets and Security
The identification of assets and security requirements
was done by analysing public development docu-
ments, wordings which form the legal basis of the
eHC and several basic IT security resources (cp. 4.1).
4.4 Analysis of the
Components-Theoretical Level
4.4.1 Cross-component Analysis
The cross-component analysis was intended to anal-
yse the processes, the mentioned components are in-
volved in. Furthermore, the cross-component analysis
included a critical review of the development docu-
ments from a security-based point of view.
Key for the Combination of Medical and Admin-
istrative Data. In (Neeb et al., 2004, p. 30)
, it is
mentioned, that security must not depend on the faith
in one single person. In (Neeb et al., 2004, p. 20)
in contrast, a requirement can be found, which pos-
tulates, that the key for the combination of medical
and administrative data of the insured, which are both
stored separately, has to be kept by the ”Beauftrager fr
den Datenschutz des Medizinischen Dienstes”, which
obviously is represented by one single person.
Unauthorised Transfer of Medical Data. In
(SGB, 2007, SGBV, 294a)
, it is postulated, that un-
der certain circumstances, medical data can be ac-
cessed by the insurance without approval of the in-
sured. This exception is given by law, but conflicts
with a general requirement mentioned in (Gematik,
Gesellschaft f
ur Telematikanwendungen der Gesund-
heitskarte mbH, 2006a, p. 63)
, which says, that no
one is allowed to access the medical data of an insured
person without his or her approval. Although, this is
a reasonable exception, it has at least to be commu-
nicated to the insured to fulfill another requirement
found at (SGB, 2007, SGBV, 291a, para. 3)
, de-
manding the insured to be told whatever happens with
his medical data. These explanations can not be found
in any of the considered documents.
cp. requirement 004.So.A.AS in (Huber et al., 2008)
cp. requirement 001.Vt.A.AS in (Huber et al., 2008)
cp. requirement 010.So.A.AS in (Huber et al., 2008)
cp. requirement 002.Vt.A.AS in (Huber et al., 2008)
cp. requirement 011.So.A.AS in (Huber et al., 2008)
Missing backup Method for Honoring Prescrip-
tions. According to (Neeb et al., 2004, p. 19)
for every process in the HTI, there has to be at least
one manually operated backup process. In (Gematik,
Gesellschaft f
ur Telematikanwendungen der Gesund-
heitskarte mbH, 2006b, p. 28)
, there can be found
one exception which combined with the following
topic might result in severe problems concerning
availability demands. There, the absence of an ad-
equate backup process for honoring digital prescrip-
tions is mentioned. Thus, an insured who has the pre-
scription exclusively digitally on his eHC, has no op-
portunity to honor this prescription when the HTI is
not available to the pharmacy. It is obvious, that this
could lead to perilous situations, if prescriptions for
immediately needed physics cannot be honored.
Possibility to Honor the Same Prescription Twice.
If the availability drawback mentioned above would
be resolved by strictly implementing the requirement
of (Neeb et al., 2004, p. 19)
and thus establishing a
manually operated backup process for honoring pre-
scriptions, every insured would have on the one hand
the digital copy of the prescriptions on his eHC, on the
other hand a paper based copy to provide a manual
backup process. This way, the insured could at first
honor his or her digital prescription as usual and af-
terwards visit a pharmacy, where the HTI is not avail-
able due to technical problems for example. There,
the insured could honor the paper based prescription,
offending several requirements concerning account-
ability and non-repudiation
Unassigned Assumption about the Security Im-
plied by the used ”Zone-Concept”. The HTI and
its related systems are divided into several zones.
This division is made, to allow a discrete view on
every zone concerning it security. As mentioned
in (Gematik, Gesellschaft f
ur Telematikanwendungen
der Gesundheitskarte mbH, 2007, p. 32), each of
these zones is considered as a closed area. However,
each of these zones is related to others using a phys-
ical connection. Wherever there is a physical con-
nection, there is also the possibility of (unauthorized)
traffic between these zones, even if the chance for this
kind of traffic might be very unlikely due to protec-
tion measures. Nevertheless, if there is the possibility
of (unauthorized) traffic, it is not feasible to consider
each of these zones for its own and even classify them
cp. requirement 002.Vf.A.AS in (Huber et al., 2008)
cp. requirement 008.Vf.K.AS in (Huber et al., 2008)
cp. requirement 002.Vf.A.AS in (Huber et al., 2008)
cp. requirements 003.Zu.A.AS, 004.Zu.A.AS and
005.Zu.A.AS in (Huber et al., 2008)
Thus, it should be contemplated, whether it might
be reasonable to expand the view and consider the in-
teraction between zones as well. Furthermore it might
be reasonable to classify each interconnected zone the
same, concerning security issues.
Adjustment of Minimum Standards happens
Infrequently. As mentioned in (Gematik,
Gesellschaft f
ur Telematikanwendungen der Gesund-
heitskarte mbH, 2007, p. 28), the minimum security
standards to be implemented on the HTI have to
be adjusted annually. According to statistics of
, in the first quarter of 2007, there have been
already 2,176 vulnerabilities announced. Regarding
the estimated amount of more than 8,000 uncovered
vulnerabilities during one year, a shorter period for
adjusting the minimum security standards could
improve security.
Inadequate Assumption about the Security of the
Systems inside the HTI. In (Gematik, Gesellschaft
ur Telematikanwendungen der Gesundheitskarte
mbH, 2006b, p. 60) it is mentioned, that all IT sys-
tems within the vpn provided by the HTI are consid-
ered to be secure. This argument is for example used
to justify the missing authentication concerning the
connection to the time servers of the HTI. As it is a
fact that there are no completely secure IT systems
this argument is not acceptable. Also IT systems con-
trolled and maintained by the HTI itself are vulner-
able for example to malware, social engineering at-
tacks, and so on.
Inconsistent with the claim cited above, in
(Gematik, Gesellschaft f
ur Telematikanwendungen
der Gesundheitskarte mbH, 2007, p. 32), it is noted,
that it is not possible to completely avoid threats and
that there will continuously emerge new threats.
Security by Obscurity. In (Gematik, Gesellschaft
ur Telematikanwendungen der Gesundheitskarte
mbH, 2007, p. 246), the Gematik claims, that security
by obscurity is not a proper approach securing IT sys-
tems. Nevertheless, the software used for eHC pur-
poses is classified as highly confidential in the same
document. This classification results from parts of the
software being intellectual property of the developing
companies. Of course, copyright issues have to be re-
garded in the eHC environment as well, but also Shan-
non’s maxime and Kerckhoffs principle
should be
Thus, at least these parts of the eHC related IT
systems, which contain security relevant processes,
cp. (Huber et al., 2008, p. 10)
cp. requirement 002.So.A.AS in (Huber et al., 2008)
should be published completely and not kept secret
to ensure intelectual property.
4.4.2 Analysis of the Connector
Imprecise Specification of the Blacklist Manage-
ment. In the security concept of the Gematik, it is
defined, that each Connector has to validate the cer-
tificate of the vpn concentrator of the central part of
the HTI
. In this context, blacklists are used to iden-
tify Connectors with revoked certificates, which have
to be updated periodical (Gematik, Gesellschaft f
Telematikanwendungen der Gesundheitskarte mbH,
2007, p. 63). Besides this definition, no further infor-
mation about implementation and handling of black-
lists can be found in any of the considered documents.
One of the most important issues is, where the Con-
nector retrieves the blacklist information from. they
can obviously not be provided by a server inside of
the HTI, as fetching the blacklist information would
come along with connecting to a potentially inse-
cure vpn concentrator. Furthermore, there are several
authentication requirements concerning the blacklist
service, which have obviously not been considered
yet. If insufficient authentication is used, an attacker
could claim to be a blacklist-server and thus provide
fake blacklists containing some or even all vpn con-
centrators of the HTI. Establishing such an attack, the
HTI would not be reachable any more because of all
of its vpn concentrators being blacklisted by an at-
Imprecise Specification of the Trusted Viewer In-
terface. According to (SigG, 2001, 2, no. 11 re-
spectively 17, para. 2) and (SigV, 2001, 15, para. 1c,
2a and 2b) the Connector has to provide a trustworthy
component - a so called Trusted Viewer component -
, which enables the verification of signatures and the
signed content. There are two possibilities of imple-
menting this component. On the one hand, the Con-
nector can contain a build in Trusted Viewer device,
on the other hand, a Trusted Viewer component can
be included as a separate component accessing an ad-
equate Connector interface over the LAN.
Concerning the implementation of the Trusted
Viewer and its interface, conflicting details can
be found in the specification document (Gematik,
Gesellschaft f
ur Telematikanwendungen der Gesund-
heitskarte mbH, 2006b). On the one hand, it is postu-
lated, that every Connector has to implement an inter-
face for the Trusted Viewer no matter if it has a built
in Trusted Viewer component or not (cp. (Gematik,
Gesellschaft f
ur Telematikanwendungen der Gesund-
heitskarte mbH, 2006b, p. 21)), on the other hand, the
cp. fig. 1
ICEIS 2008 - International Conference on Enterprise Information Systems
Connector has to implement the Trusted Viewer in-
terface only if it does not contain a Trusted Viewer
component on its own (Gematik, Gesellschaft f
Telematikanwendungen der Gesundheitskarte mbH,
2006b, p. 45 and p. 136).
Security Issues Concerning the Communication
with the Trusted Viewer. Between Connector and
Trusted Viewer, all communication has to be se-
cured by SSL according to (Gematik, Gesellschaft f
Telematikanwendungen der Gesundheitskarte mbH,
2007, p. 172)
, (Gematik, Gesellschaft f
Telematikanwendungen der Gesundheitskarte mbH,
2007, p. 137)
and (Gematik, Gesellschaft f
Telematikanwendungen der Gesundheitskarte mbH,
2006b, p. 137)
. In (Gematik, Gesellschaft f
Telematikanwendungen der Gesundheitskarte mbH,
2006b, p. 137), it is mentioned, that the Trusted
Viewer will most likely be implemented as a sepa-
rate piece of software. Thus it would reputedly not
be a security improvement to provide the this com-
ponent with an own identity. According to this, the
Trusted Viewer will de facto have no own identity
which implies, that authentication between Connec-
tor and Trusted Viewer will be if at all one-sided, sup-
porting man-in-the-middle attacks.
Nevertheless, in case there would be a two-way
authentication, it might be possible, to use fake cer-
tificates for a man-in-the-middle attack between Con-
nector and Trusted Viewer. So far, it is not specified,
how the Trusted Viewer should verify the Connector’s
certificate and vice versa. Fourthermore it is not spec-
ified what happens, if a man in the middle attack be-
tween Connector and Trusted Viewer is established
with fake certificates. Will the user be prompted that
the certificate is fake? Where will he be prompted?
How can be assured, that a user does not ignore the
The worst case of a successful man-in-the-middle
attack according to this issue could for example be the
forgery of prescriptions.
A possible man-in-the-middle attack scenario
based on the weakness described above can be found
at (Huber et al., 2008, p. 73)
Security Issues Concerning the Communication
with the Primary System. The problems illus-
trated in 4.4.2 can partially be adopted for the com-
munication between Primary System and Connec-
tor. In none of the regarded documents, there can
be found any requirement concerning an authentica-
tion between these two components besides the gen-
cp. requirement 005.In.K.AS in (Huber et al., 2008)
cp. requirement 011.Vt.K.AS in (Huber et al., 2008)
cp. requirement 026.In.K.AS in (Huber et al., 2008)
erally postulated use of SSL for the communication
between components in the decentral part of the HTI
(cp. (Gematik, Gesellschaft f
ur Telematikanwendun-
gen der Gesundheitskarte mbH, 2007, p. 172)
(Gematik, Gesellschaft f
ur Telematikanwendungen
der Gesundheitskarte mbH, 2007, p. 137)
(Gematik, Gesellschaft f
ur Telematikanwendungen
der Gesundheitskarte mbH, 2006b, p. 137)
). If
there will be an authentication between these two
components, it probably would only be one-sided,
due to the lack of a requirement demanding the Pri-
mary System to provide its own identity. The missing
or just one-sided authentication enables the establish-
ment of man-in-the-middle attacks between Connec-
tor and Primary System.
Even if there was an authentication between Pri-
mary System and Connector, at least the Primary Sys-
tem could not verify the Connectors identity. There-
fore, the Primary System would have to verify the
identity by using some kind of service, provided by
the HTI. According to (Gematik, Gesellschaft f
Telematikanwendungen der Gesundheitskarte mbH,
2007, p. 177), the direct access of the HTI by a Pri-
mary System is strictly forbidden, and the Connector
itself does actually not provide a service like this as
The worst case of a successful man-in-the-middle
attack according to this issue could for example be the
illegal retrieval of sensitive medical data of an insured
4.4.3 Analysis of the Primary System
Insufficient Classification of the Data Processed.
Acoording to (Neeb et al., 2004, p. 21), the secu-
rity level of the data processed by a Primary System
is classified as low or medium. The requirements of
these levels are allegedly covered by the security mea-
sures of an actual Primary System. According to the
classification of IT-Grundschutz
, the abuse of the
concerning data would result amongst others in the
the abuse would have only marginal legal conse-
the effects on the social position and the financial
circumstances of the person concerned would be
the tolerable downtime of the Primary System
would be 24 hours
cp. requirement 005.In.K.AS in (Huber et al., 2008)
cp. requirement 011.Vt.K.AS in (Huber et al., 2008)
cp. requirement 026.In.K.AS in (Huber et al., 2008)
the financial loss of the institution using the Pri-
mary System would be tolerable
It is obvious, that the tolerable downtime of sys-
tems in the healthcare sector is in most cases not as
long as 24 hours. Hospitals definately can not afford
downtimes of their IT systems as long as 24 hours.
Furthermore, the abuse of private, medical data of an
insured can result in severe consequences - for exam-
ple the anamnesis of a person in the hands of his or
her employer or insurance company.
Unassigned Assumption about the Presence of Se-
curity Measures Provided by Present Primary Sys-
tems. According to (Neeb et al., 2004, p. 21), the
security measures used in a present Primary Systems
are sufficient to assure the postulated level of security
for the processed data, which is classified as normal
based on the categorisation of IT-Grundschutz
To verify this claim, some of the major manufac-
turers of Primary Systems have been asked wheter
they provide for example encryption of sensitive data
or role based and password protected user access. 4
of 17 addressed companies answered and confirmed
to provide some kinds of security measures in their
products. So on the one hand, the claim has been ver-
ified, but on the other hand, the question comes up
why the remaining companies did not respond at all
and whether this behaviour is related to providing se-
curity features or not.
In contrast to the four companies providing secu-
rity features in their products, the designee for data
protection and freedom of information in Germany,
Peter Schaar claims, that the present Primary Systems
frequently do not offer any access control or encryp-
tion features (cp. (, 2005)).
4.4.4 Analysis of the Card Reader
As the used card reader is a Secure Interopera-
ble ChipCard Terminal(SICCT) standardised, self-
contained piece of hardware, its development is not
part of the eHC development process and thus it
would be no benefit to analyse it in detail. The ter-
minals are being analysed during their development
and certification process. Thus, the card terminals
were only considered from a general point of view
in the present work, whereas no weaknesses could be
revealed. Due to its own digital certificate, the com-
munication between other components and the card
reader can be secured by a strong authentication. Fur-
thermore, the card reader is sealed physically, so ma-
nipulation attempts can be detected easily.
Nevertheless, a practical analysis of this compo-
nents might be interesting as thus, for example imple-
mentation deficiencies could be uncovered. As men-
tioned in 4.5, no card terminal was actually available
for analysing activities, so these actions have to be
done in future work.
4.4.5 Attack-Tree Analysis
As one tool of step three in the developed analysis
approach, an Attack-Tree Analysis has been made to
identify the most likely and easy attacks. Within the
analysis, Attack-Trees for each of the components de-
spite of the Primary System have been made. The Pri-
mary Systems were excluded from this analysis step
due to the different kinds of available Primary Sys-
tems. There is no standardised Primary System due
to the freedom of each manufacturer to implement a
Primary System in his favourite way.
The result of the Attack-Tree analysis were two
large Attack-Trees for the Connector and the card ter-
miinal including over 600.000 attack-scenarios each.
The Attack-Trees can be used for further work,
when the related components are present. Concern-
ing the work in (Huber et al., 2008), it emerged, that
attacks on a technical level are mostly very expen-
sive or out of scale regarding the expenditure of time.
As also some non or semi-technical ways to achieve
an attackers goal have been included in the Attack-
Tree Analysis for completeness, it showed up, that the
most likely attacks are the ones using bribing, black-
mailing or spying out confidential information like ac-
cess data. These attacks in turn are typical for attack-
ers belonging to the groups of organised crime and
terrorism as mentioned in 4.2.
4.5 Analysis of the
Components-Practical Level
At the beginning of the analysis in november 2006, it
was planned to have some prototypes of the concern-
ing components for analysing purposes within a few
weeks. Unfortunately, just until the end of the analy-
sis process, no hard- or software components usable
for practical tests were available, mainly due to delays
within the development process. Thus, none of the
steps, planned for practical analysis activities could
be executed and none of the revealed issues could be
approved by further practical tests.
In the course of the present work, a new approach was
developed, to fit the needs of a security analysis from
a technical point of view. This approach based on ISO
ICEIS 2008 - International Conference on Enterprise Information Systems
27001, was used to analyse the components Connec-
tor, Primary System, Card Terminal and some of their
interaction processes wihtin the HTI. As a result of
the analysis, 14 deficiencies could be revealed, in-
cluding weaknesses, inconsistent and conflicting de-
velopment documents and violation of security de-
For future work, the analysis offers various start-
ing points such as the constructed Attack-Trees or the
revealed weaknesses which can and should be verified
in practice as soon as the considered components are
physically available for testing purposes.
Anderson, R. (2001). Security Engineering: A Guide to
Building Dependable Distributed Systems. Wiley &
Sons, 1 edition.
BDSG (2003). Bundesdatenschutzgesetz in der Fassung
der Bekanntmachung vom 14. Januar 2003 (BGBl. I
S. 66), zuletzt ge
andert durch Artikel 1 des Gesetzes
vom 22. August 2006 (BGBl. I S. 1970).
BSI, British Standards Institution (1999). BS 7799-
2 1999 Management von Informationssicherheit :
Teil 2: Spezifikation fr Informationssicherheits-
BSI, Bundesamt f
ur Sicherheit in der Informationstechnik
(2004). Studie zu ISO-Normungsaktivitten ISO/BPM
- Anforderungen an Information Security Manage-
ment Systeme. (2005). Datenschutzbeauftragter Schaar zur
eCard: Es gibt keine 100prozentige Sicherheit. Inter-
view von mit dem Bundesbeauftragten f
den Datenschutz und die Informationsfreiheit (BfDI)
Peter Schaar am 21.09.2005.
Gematik, Gesellschaft f
ur Telematikanwendungen der
Gesundheitskarte mbH (2005a). Gematik Fachmod-
ell. Version 0.9.
Gematik, Gesellschaft f
ur Telematikanwendungen der
Gesundheitskarte mbH (2005b). Gesamtarchitektur -
Kryptographische Ziele der Telematik. Version 1.0.
Gematik, Gesellschaft f
ur Telematikanwendungen der
Gesundheitskarte mbH (2006a). Einf
uhrung der
Gesundheitskarte - Gesamtarchitektur. Version 0.2.0.
Gematik, Gesellschaft f
ur Telematikanwendungen der
Gesundheitskarte mbH (2006b). Einf
uhrung der
Gesundheitskarte - Konnektorspezifikation. Teil 1 -
Allgemeine Funktionen und Schnittstellen des Kon-
nektors. Version 0.6.0.
Gematik, Gesellschaft f
ur Telematikanwendungen der
Gesundheitskarte mbH (2006c). Einf
uhrung der
Gesundheitskarte - Spezifikation Infrastrukturkompo-
nenten: Zeitdienst. Version 1.0.0.
Gematik, Gesellschaft f
ur Telematikanwendungen der
Gesundheitskarte mbH (2007).
Sicherheitskonzept der Telematikinfrastruktur. Ver-
sion 1.9.0.
Gerloni, H., Oberhaitzinger, B., Reier, H., and Plate, J.
(2004). Praxisbuch Sicherheit f
ur Linux-Server und
Netze. Carl Hanser Verlag, M
unchen Wien.
Gollmann, D. (2006). Computer Security. Wiley, 2nd edi-
Haux, R. (2005). Health information systems - past,
present, future. International Journal of Medical In-
formatics, 75:268–281.
Heeks, R. (2006). Health information systems: Failure, suc-
cess and improvisation. International Journal of Med-
ical Informatics, 75:125–137.
Huber, M., Sunyaev, A., and Krcmar, H. (2008). Arbeitspa-
pier 32 - Technische Sicherheitsanalyse der elektro-
nischen Gesundheitskarte. Technical report, Technis-
che Universit
at M
unchen, Lehrstuhl f
ur Wirtschaftsin-
ITGI, IT Governance Institute (2007). Cobit 4.1.
Lorence, D. and Churchill, R. (2005). Incremental adop-
tion of information security in health-care organiza-
tions: implications for document management. In-
formation Technology in Biomedicine, IEEE Transac-
tions on, 9(2):169–173.
Neeb, J., Bunz, H., and Biltzinger, P. (2004). Erarbeitung
einer Strategie zur Einfhrung der Gesundheitskarte -
Schabetsberger, T., Ammenwerth, E., Andreatta, S., Gratl,
G., Haux, R., Lechleitner, G., Schindelwig, K., Stark,
C., Vogl, R., and Wilhelmy, I. (2006). From a paper-
based transmission of discharge summaries to elec-
tronic communication in health care regions. Inter-
national Journal of Medical Informatics, 75:209–215.
Schneier, B. (2004). Secrets and Lies : Digital Security in
a Networked World. Wiley.
Schweiger, A., Sunyaev, A., Leimeister, J., and Krcmar, H.
(2007). Information systems and healthcare xx: To-
ward seamless healthcare with software agents. Com-
munications of the Association for Information Sys-
tems, 19:692–709.
SGB (2007). Sozialgesetzbuch. DTV-Beck.
SigG (2001). Gesetz
uber Rahmenbedingungen f
ur elek-
tronische Signaturen (Signaturgesetz - SigG) - Sig-
naturgesetz vom 16. Mai 2001 (BGBl. I S. 876),
zuletzt ge
andert durch Artikel 3 Abs. 9 des Gesetzes
vom 7. Juli 2005 (BGBl. I S. 1970;
anderung durch
Art. 4 G v. 26.2.2007 I 179 zuk
unftig in Kraft).
SigV (2001). Verordnung zur elektronischen Signatur (Sig-
naturverordnung - SigV) - Signaturverordnung vom
16. November 2001 (BGBl. i S. 3074), ge
andert durch
Artikel 2 des Gesetzes vom 4. Januar 2005 (BGBl. I
S. 2).
StGB (2005). Strafgesetzbuch. DTV Deutscher Taschen-
buch Verlag.