A Rationale-based Model for Architecture Design Reasoning
A Rationale-based Model for Architecture Design Reasoning
A Rationale-based Model for Architecture Design Reasoning
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
10.3. <strong>Reasoning</strong> about change impact with AREL<br />
network may be vulnerable to attack. It is possible to tamper with the payment messages<br />
by intruding the networks or the computers. So security protection of payment messages<br />
is a key issue in designing payment system. The following are three additional security<br />
requirements that need to be considered in message processing:<br />
• R2 4 3 Privacy of Payment Message - payment messages are encrypted to protect<br />
the privacy and confidentiality of the transaction.<br />
• R2 4 1 Payment Message Authenticity - when a payment message is authenticated,<br />
it means that the system recognises that this payment message can only be sent<br />
by the authorised person or organisation. The non-repudiation characteristic of<br />
payments thus <strong>for</strong>ms the legal basis of a payment system.<br />
• R2 5 7 Payment Message Integrity - this mechanism ensures that the payment message<br />
has not been modified in any way during its transmission. It is used to protect<br />
the payment message from hackers and transmission errors.<br />
In Figures 10.4, we show the security design decisions using the AREL representation.<br />
Decision AR29 is about the implementation <strong>for</strong> the privacy requirement, it was decided<br />
that a software algorithm would be used to implement this feature. Similarly, AR17<br />
and AR12 are decisions to implement design objects to cater <strong>for</strong> both the authenticity<br />
requirement and the message integrity requirement using a software module C4 2 5. This<br />
module basically calculates a Message Authentication Code (MAC) which is <strong>based</strong> on a<br />
special key shared between the sender and the receiver only. If the code checks out, then<br />
it proves that the message is originated from a specific sender and no one else. It also<br />
proves that the message has not been tampered with during its transmission.<br />
Now that a software algorithm to guarantee payment messages’ privacy and authenticity<br />
is used, one must be certain that the security keys used in the calculation cannot<br />
be compromised. Thus, decision AR30 is made to manage the security keys <strong>for</strong> such<br />
purposes. At the time of the decision, PKI was not commercially available in the chosen<br />
plat<strong>for</strong>m and so this alternative was not implementable.<br />
As part of the validation, we need to decide on how to manage the processing sequence<br />
(i.e. AR13 ). The sequence number ensures that the payment message to guarantee that<br />
there are no gaps in a series of messages. If the check fails, then the payment message is<br />
rejected, this is achieved by C4 2 9.<br />
Figures 10.5(a) and 10.5(b) show the BBN representation of an AREL model <strong>for</strong> the<br />
system with probability tables showing the prior probabilities and CPTs of the payment<br />
178