On Tue, 17 Mar 2015 17:58:16 +0100, Thomas Berg <[email protected]> wrote:
>May an ignorant peek in here... :) > >Just as a concept and theoretically; wouldn't a way to secure that the key 8 >storage is untouched is to save a hash of the content in >system key area >(with a random salt) ? Then just compare the hashes before reusing the key 8 >data. >Of course, this is only feasible if performance is not a problem. > That does not "secure" the storage; it merely lets you tell if it has been corrupted. And you might have a lot of storage, with complex structure, that you need to handle that way. Still, that approach might be a start, but since it doesn't really solve the issue. And there are other issues that it doesn't being to address, so I would look for a different approach that actually prevents the unauthorized program from interfering with you. I've seen too many cases of people designing solutions that they think will allow safe intermingling of trusted authorized code with unauthorized code, and it often devolves into a game of whack-a-mole. You think of an issue, and defend against it. The attacker comes up with an issue you didn't consider, so you patch your program to get around that. Then the attacker comes up with another attack for you to patch against, and another, and ... It's best not to play that game. You need a design that fully isolates you in the first place. -- Walt ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
