Your basic premise is flawed ( as many companies have discovered, and decided to ignore ) - You want your end user to not be able to view the data[1] but be able to view the data[2].
In order to achive [2] you automatically open up for [1] - why?
Well in order to decrypt your data for you application to present it your application needs the key - that means that your user have access to the key.
And yes this may be out of scope of the average user, but though the magic of the internet all it takes is one user who can figure it out.
if your worried about file altering being used for cheating, you could simply use the "streaming update" trick - basically you roll out updates on per file / data chunk basis form minor updates. This requires you to check the files /data chunks and submit their check sum to the server to see if an update is available. Anyone who has a bad checksum ( ie one that matches no version ) gets marked in the black list table. Every few weeks you go through the black list table and do a "ban wave" for breaking the EULA.
The reason you wait a few weeks is to make sure you catch all offenders.
Do note that this will be defeated in time as well (when people realize why they get banned) by intercepting your check sum calls and returning "proper" values - The trick to counter this is to update the exec to alter the offset often enough that it becomes too annoying for the cheat/bot author to keep publishing.
But even this is a loosing battle ( just ask blizzard ) - the more people playing your game the more likely one of them will be more clever than you and beat you at the cheat anti-cheat battle. At this point you need to tell your lawyer to "go get them", see: http://en.wikipedia.org/wiki/MDY_Industries,_LLC_v._Blizzard_Entertainment,_Inc.
The idea here being to hit the so hard nobody want's to risk it again