Influence of Architectural Styles on Security

[ Pobierz całość w formacie PDF ]

having to fear prosecution by backtracking through the web of trust. Changes in the web
of trust should be recorded so that after-the-fact investigations if the integrity might have
been compromised are possible. If the integrity of the web of trust is compromised and
it is not possible to either investigate and recover from the damage or setting the system
back to a known safe state this would mean that CAcert would have to rebuild the web
of trust from scratch and therefore probably mean the end of existence for the project.
43
44 A. Requirements
A.3.1.2. Confidentiality
To protect information about relationships between users, which might be considered per-
sonal data, the connections in the web of trust should not be public. If the relationship
data leaks it might result in bad publicity.
A.3.2. Login/Recovery Credentials
A.3.2.1. Integrity
If an attacker is able to set new credentials he has full access to the account and can issue
certificates in that users name and if the user has Assurer status he might falsely verify
his own account for a fake identity. If multiple accounts get compromised in this way
(especially Assurer accounts) and it can be determined to which accounts this applies, a
whole subgraph might need to be removed from the web of trust which is not desirable
but feasible. If it is not possible to determine which accounts have been compromised then
essentially the integrity of the web of trust is compromised and the same ways of recovery
or failure to do so apply. Changes of login or recovery credentials should be recorded so
that an investigation of accounts which might have been compromised is possible.
A.3.2.2. Confidentiality
A user might against all advice use the same password for multiple services so even if
CAcert is compromised the credentials stored should not be useful for logging into other
services. If an attacker recovers the credentials for an account in a usable way he has full
access to the account and might perform any attack described in the previous section. Even
if the credentials are recovered in an unusable way it might still result in bad publicity.
A.3.3. User Data
A.3.3.1. Integrity
If an attacker is able to modify the data of his account after he already got Assured or
add an email address or domain he does not have control over, he might issue certificates
for a fake identity. These fake identity certificates might in turn be used to compromise
other systems (e.g. secure network connections) and result in a major loss of trust in
CAcert certificates. Changes of user data should be recorded so that an investigation of
unauthorised changes is possible.
A.3.3.2. Confidentiality
To protect personal data about the user, this information should not be public. Assurers
might access some of this data on entering the primary email address in order to assure the
user. Failure to enforce confidentiality of private user data might result in bad publicity
and many users requesting to delete their data.
A.3.4. Issued Certificates
A.3.4.1. Integrity
While integrity of the certificates themselves stored for the retrieval by the user is not
required as they contain inherent integrity checks, some metadata, like which certificate
belongs to which user account is critical. If an attacker could associate his certificate with
the user account of another user he might be able to use it to login as that user (especially
for login-only certificates), effectively resulting in an integrity violation of login credentials.
All issuing of certificates should be recorded so that false metadata can be identified.
44
A.3. Critical Assets 45
A.3.4.2. Confidentiality
Certificates should not be public as they might contain personal user data. If the confi-
dentiality is violated it might result in bad publicity for CAcert.
A.3.5. Revocation Information
A.3.5.1. Integrity
If an attacker is able to mark a compromised certificate as not revoked, he still may use
this certificate even if the software validating the certificate does revocation checking.
Therefore every revocation of a certificate should be recorded so that an investigation and
recovery is possible. If such an attack succeeds it might have an impact on trust in CAcert
certificates.
A.3.5.2. Availability
If the revocation status of a certificate is not available at the time of verification, the
software verifying might react by either warning the user or even marking the certificate
invalid or just ignoring this kind of error. Warnings or treating the certificate as invalid
might give the impression that the connection is insecure when in reality this is not the
case or even worse ignoring the error might lead to putting trust in a certificate that has
been compromised. Low availability of revocation information gives the impression that
the CAcert service is unreliable, web site owners might complain about inaccessibility for
their users and software vendors will ignore revocation status checking errors because of
the infeasibility of strict checking. The revocation status providing services should be
redundant for these reasons.
A.3.6. Root/Subroot Certificates
A.3.6.1. Integrity
If an attacker is able to replace the root and subroot certificates with his own certificates,
users coming to the CAcert website to install the CAcert root certificates might install
the attackers certificate. Although there also is the unsolvable problem that the data is
changed in transit, this would probably only affect a few connections while replacing the
certificates on the website would be persistent and therefore affect more users. The real
solution to the problem would be that users verify the fingerprint of the certificate which is
distributed out-of-band or receive the certificate in another secure way, but to be realistic
one has to assume that this is not done by every user. If an attacker is able to replace the
root certificate this might result in bad publicity for CAcert. [ Pobierz całość w formacie PDF ]

Pokrewne