19.12.2012 Views

IT Baseline Protection Manual - The Information Warfare Site

IT Baseline Protection Manual - The Information Warfare Site

IT Baseline Protection Manual - The Information Warfare Site

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Safeguard Catalogue - Personnel Remarks<br />

____________________________________________________________________ .........................................<br />

- Resistance to forging: for anyone who is not in possession of the key it<br />

must be "practically impossible" to calculate the MAC value of a new<br />

message, even if he has come into possession of a number of old messages<br />

with the associated MAC values.<br />

If Alice and Bob have a MAC and a common, secret MAC key, Alice<br />

authenticates her message simply by calculating the MAC value of the<br />

message and sending it to Bob together with the message. In turn, Bob<br />

calculates the MAC value of the received message with the MAC key, which<br />

is also known to him. If this tallies with Alice’s value, he can assume that the<br />

message is authentic (i.e. that it has not been altered and that it really<br />

originates from Alice). Alice has therefore authenticated her message to Bob<br />

by using the key that is known only to Bob and herself.<br />

MACs are often designed on the basis of symmetric encryption methods. <strong>The</strong><br />

best known variant is the encryption of a message with DES or another block<br />

cipher algorithm in CBC or CFB mode. This involves appending the last<br />

encrypted block to the message as the MAC. Apart from this, however, there<br />

are also MACs that are not based on encryption methods. <strong>The</strong> MAC value of a<br />

message can be seen as the non-forgeable, key-dependent, cryptographic<br />

checksum of the message. <strong>The</strong> use of MACs for the purpose of authentication<br />

requires that both parties reliably protect the secret authentication key.<br />

As a side-effect of integrity protection, the procedures outlined above can be<br />

used at the same time by the recipient of the message to check that the<br />

message, which has been verified as being unmanipulated, could only have<br />

been sent by the sender who is actually known to the recipient. This<br />

conclusion can be drawn because only this sender has the necessary keys for<br />

encrypting and determining the check information.<br />

III. Proof of authenticity<br />

Certain criteria must be met regarding the authentication of users with respect<br />

to communication partners/<strong>IT</strong> systems or of clients with respect to servers:<br />

- Illegitimate accesses must be detected and warded off<br />

- Legitimate accesses must be permitted<br />

- Sensitive data must remain protected even when transmitted across<br />

networks<br />

To ensure this, procedures are required which allow all participants to<br />

establish the identity of their communication partners unequivocally. This<br />

includes a time aspect: Alice wants to convince Bob in real time that it is<br />

indeed she who is communicating with him. <strong>The</strong> main techniques for<br />

authentications of this nature are cryptographic challenge-response protocols.<br />

In these, Bob sends data to Alice and requests (challenges) her to prove to him<br />

that she possesses a secret (i.e. an item of key information); Alice<br />

demonstrates to him that she has this possession without divulging the secret<br />

itself by sending him a response that is dependent on the secret and on his<br />

challenge. Bob in turn uses the response that she has sent to check that the<br />

correct secret really was used to calculate the response.<br />

____________________________________________________________________ .........................................<br />

<strong>IT</strong>-<strong>Baseline</strong> <strong>Protection</strong> <strong>Manual</strong>: Oktober 2000

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!