MeatballWiki | RecentChanges | Random Page | Indices | Categories

There are five basic principles of information security. A truly TrustedSystem will provide

All of these can be done with cryptographic means. They can also be done to a looser degree with the existing postal system (surface mail).


Isn't DataConfidentiality? something that comes under UserAuthorization? rather than a separate heading?

(I've separated out some comments which were conflated; this makes the reply below harder to follow but I couldn't follow it before anyway.)

Not exactly. Consider the cases where the government insists that all the messages are in cleartext, but you still want to ensure that the message is not tampered with. This would also be important for contracts, I suppose. Moreover, DataConfidentiality? and DataIntegrity? typically involve different technologies. Confidentially can be given by encrypting the whole message, whereas integrity can be done more cheaply by only hashing the message (ala with a DigitalSignature with appendix).

Finally, authorization requires something outside as well as the encryption. Confidentiality only means no one can read it except the two involved parties. Authorization means that the other party is allowed to send that message. For instance, with PublicKeyCryptography, anyone can send an encrypted message to a bank. But is that person really allowed to withdraw money from your account?

Nonetheless, you are correct that you can usually get more than one at a time with one algorithm. An appropriate public key policy will give you all three.

I still don't follow. In one case we have "No un-authorized person can read" and in the other, "No person can read". The second is just the first with the addition that no-one is authorized. Replace "can read" with "can send" or "can edit" or any other act.

UserAuthorization? seems to be at a different level of abstraction to DataConfidentiality? so it is funny to see them in the same list.

UserAuthorization? is not necessarily "who can read." It's also about "who can send." Anyone can encrypt an e-mail to a bank, but you are the only one authorized to withdraw from your account. There are some situations when the message must not be encrypted yet still be authenticated and authorized. Authorization can be done cryptographically by handing out authorizing keys in addition to authentication keys. This is like giving you the generic key to the bank vault, but having you sign in personally when you enter.

It's also about "who can send" - that's why I wrote 'Replace "can Read" with "can send"' above. It seems to me that DataConfidentiality? is a special case of UserAuthorization?.

Isn't DataIntegrity? something that comes under UserAuthorization? rather than a separate heading, at least if we ignore non-user problems (such as disk crashes).

DataIntegrity? is a completely seperate problem. It prevents tampering or errors in the stream. Suppose you encrypted a random key. If you change some bits, it will probably still decrypt to something meaningful. An attacker can confuse his victims just by twiddling some bits, even if it doesn't give him access to the message. Consequently, you need some sort of signature to verify the data is correct.

Yes; DataIntegrity? comes under restricting authorisation for changes. Again, it's a special case of UserAuthorization?.

Really, the best answer is to define the above terms.

We seem to agree on what they mean.

Should there be a heading for AuditTrail, that tells you who did what, retrospectively?

Maybe. Or maybe we can put AuditTrail on HardSecurity as well, as well as the PrinciplesOfInformationSecurity?? Maybe we should ask our local munitions experts. (Cliff? Dave?)

I'll look into putting something into there. I just picked upt the big red scary book (AppliedCryptology?) , but I've not read anything about it yet. --DaveJacoby


MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions