Since you mentioned that that your application can launch the child application, you should communicate via an inherited handle to minimize the risks associated with more open types of IPC. Makes sure to use an unnamed object; a locally created pipe should be fine. You can use DuplicateHandle (which you have to pInvoke from C#) to create an inheritable handle. You can pass the handle value to the child by any means necessary-- even the command line to launch the child, and it would still be secure, because the handle value is meaningless to all other processes.
The only remaining problem is making sure they binaries themselves are what you expect. You should sign your binaries with a strong name. You should be able to read back the key from any assembly with
Assembly App2 =... App2.GetName().GetPublicKey();
However, it is somewhat difficult to set up both to authenticate each other in this manner. Is it really necessary to ensure the parent app is unmodified? If an attacker has modified the parent app, they can likely do anything they want to your program anyway. You could try strong named assemblies... they make modification of either App1 or App2 difficult, but it's a beatable scheme because an attacker can basically resign the whole assembly. But if you have an attacker who can replace your main app, you're probably already lost so it might not even be worth pursuing.
You should carefully consider if an attacker even has a realistic way to replace your binaries. If you're stuff is ACL'd to require administrator privileges (e.g. by an installer), then you should probably consider them to be secure. There is no way to secure yourself against an administrator, your only hope is obfuscation at that point.
Once you feel reasonably assured that your binaries are unmodified, I don't think you need to encrypt to send between them as long as you have a secure enough channel like an unnamed object local to those processes. I think a properly unnamed pipe is already secure enough not to require encryption, as long as the endpoints are legit. Would be worth a second opinion though. (If you really do need to encrypt for some reason you should do a real key exchange like Diffie-Hellman)
EDIT: after finding out App1 is an html page... In general, there is no way for App2 to secure itself against App1 if App2 cannot communicate with App1. An attacker can duplicate the launch command used by App1. You're reduced to obfuscation and hoping, which isn't really security. If you're handling sensitive data, this probably warrants a redesign. I'm not an expert on HTML, but two-way communication might actually be possible. Also, consider a third-party agent which manages the session remotely.
