Information Technology Reference
In-Depth Information
operation
decrypt()
that calculates the plaintext
pt
given the ciphertext
ct
and the
cryptographic key
ck
, which has to be equal to the cryptographic key used for the
encryption process. This relation between the encryption and decryption func-
tions can be formally expressed as follows:
|
decrypt
(
encrypt
(
pt
,
ck
)
,
ck
)=
pt
.WeequiptheGSC
SymmetricEncryptorDecryp-
tor
with the stereotype
∀
pt
:
Data
;
ck
:
CryptographicKey
critical
, and we assign the plaintext
pt
to the tag
{
secrecy
}
, since the goal of this GSC is to keep the plaintext confidential.
In the next section, we explain how different GSCs and GNCs are combined
to obtain patterns for secure software architectures related to CSPFs.
3.3
Generic Security Architectures
We combine the GSCs and GNCs constructed or selected for a given CSPF to
obtain
generic security architectures
(GSA). Such a GSA represents the struc-
ture of the machine domain of the CSPF. Since GSCs and GNCs are platform-
independent, so are GSAs. Based on the connection of CSPFs and GSAs, trace-
ability links are introduced. Hence, our approach allows to understand which
security requirements are realized by the different parts of a software architec-
ture. This improves the maintainability of the software. Similar to GSCs and
GNCs, we specify GSAs based on structural views using UML2.3 composite
structure diagrams, and control and data flow views using UML2.3 sequence
diagrams. The structural as well as the behavioral views of GSAs comprise the
composed views of the GSCs and GNCs they consist of. We construct GSAs
according to the following procedure:
1. An adequate basic software architecture to connect the GSCs and GNCs has
to be selected. The GSA presented in the following and the ones introduced
in [14, pp. 160 ff.] organize the components in a layered architecture. For
this purpose, each of the GSAs contains an
application
component, which
coordinates the behavior of all other components and provides a simplified
interface (compared to directly using the interfaces of the components it
connects) to the environment.
2. If components can be connected directly, one connects these components.
3. If components cannot be connected directly (e.g., because a component pro-
duces incompatible output for another component), additional
adapter
com-
ponents to connect them must be introduced.
4. Interfaces between the machine and its environment must be designed in the
GSA according to the interfaces of the machine domain of the corresponding
CSPF.
We enrich GSAs with UMLsec4UML2 language elements to express security
properties based on the CSPFs the GSAs are related to. We apply the stereotype
secure dependency
to the specification of the structural views of GSAs
according to the following procedure:
1. The structural view of a GSA should be organized in a package stereotyped
secure dependency
, which contains a class diagram to define port types