activity_diagrams

[Impressum] [E-Mail]

Modeling Debitcard (4)

Handshake protocol as activity diagram

It establishes a secure session between Debitcard and OnlinebankingService. This protocol uses security data types defined in SecureMDD to secure the messages. We use private and public keys as well as nonces and states to exchange a session key to secure messages over an intermediate like in this example the PC component. There are four participants involved in this scenario. The AccountOwner ao, the PC pc, the Debicard card and the OnlinebankingService obs. First the message UHandshake is sent over the pc to card (1). Then if the state is IDLE, a fresh nonce will be created, wrapped in the class ClientHelloMsg and encrypted with the public key publicKeyOBS. Then the state will be changed and the encrypted nonce together with a certificate, consisting of the signature of the card's public key and the card's public key self, will be sent over pc to obs (2). But before pc can forward this message, it is necessary to know which instance of OnlinebankingService should be used. Because obs has to store session dependent information like states and the exchanged session key it is not possible to use the same instance for all invokers. For that OnlinebankingService is stateful and provides a new instance for every invoker. Because the same instance should also be used in another protocols, it is necessary to model the first call of a stateful service. Therefore the stereotype <<openSession>> is supported and can be applied to a send signal action. Now card communicates with its own OnlinebankingService instance obs. After obs receives the message, it also checks if its state is IDLE and verifies the received certificate. If the the certificate is valid (3), obs decrypts the received nonce, creates another one, wraps the two nonces in the class ServerHelloMsg and encrypts it with the received public key. After that, the state will be changed and the encrypted nonces are sent to card (4). card checks the state and ensures that the last received message was Handshake and that no exception occurred. It encrypts the received nonces and checks that the first nonce is equal to the nonce that was generated in the previous card step (5). If the comparison was successful, the card creates a session key, stores it, wraps the session key and the nonce created by obs in SessionKeyMsg and encrypts it with the public key that belongs to obs. After that the card state is set to AUTHENTICATED and the session key together with the nonce will be sent to obs (6). obs receives the message, checks its state, encrypts the message, compares the nonce, stores the session key, sets its state to AUTHENTICATED and returns a non-security critical message HandshakeSuccessful (7). The used messages in this protocol are depicted in the class diagram.

OnlineTransaction protocol as activity diagram

It shows the protocol to transfer money from one account to another one. After the session key is exchanged and the states are set to AUTHENTICATED, the online transaction can be processed. The account owner (card holder) has to type in the transaction data, namely the PIN, the amount of money that should be transferred and the receiver account information. This data (uoti) will be sent over pc to the card (1). The card checks that the card state is AUTHENTICATED, wraps uoti and the account information (accountInfo) that is initially stored on the card in the message TransactionData and encrypts it with the previously exchanged session key. Then the state is set to IDLE and the encrypted data is sent to obs over the pc (2). After obs receives the message TransactionData it checks that its state is also AUTHENTICATED and decrypts the received data with the previously exchanged session key. The state is set back to IDLE to avoid replay attacks and on the basis of the card holder's bank code it is checked which bank the card holder account belongs to. Dependent on this the message is sent over the port affiliated to the affiliated bank (3) or over the port directly to the direct bank (4). The ports are modelled in the deployment diagram. If bank b1 receives a transaction message with PIN, the amount of money that should be transferred, the sender account information and the receiver account information it checks if the card holder account belongs to it (5). If so, it checks if the receiver account also belongs to it and processes the transaction internally (6). Otherwise, the bank deducts the sum from the card holder account (7) and sends a request to the bank of the receiver account (8) to increase the sum in its account (9). If this fails (e.g. because of a non-existent account number) bank b1 is notified, and the deduction from the card holder account is revoked (10). The failure (denoted by the flow final) will be propagated back to the user. Otherwise, the transaction was successful and a message is sent back over obs and pc to the user (11). But before the notification is sent to the user, pc closes the session with obs using the stereotype <<closeSession>>.

An online transaction between different banks must avoid that money is deducted from one account but not deposited to another account. For this it is necessary that the messages during a transaction always arrive in the correct order. This is guaranteed

in our example because the attacker has only the ability to read messages on the connection between affiliated bank and direct bank (see deployment diagram, with a full Dolev-Yao attacker we cannot ensure that a protocol ever finishes). Because this connection is secured with Transport Layer Security (TLS) the attacker can read only the encrypted messages.

Subactivity diagrams used in the onlineTransaction protocol

Back, continue to the generated code