In reading about the One-time pad it appears to need truly random key for the pad. Since true random values are not practical to generate this presents a problem (thus making One-time pad less practical). If instead I use the operating system provided CSPRNG to generate the key, is that any better than using AES in GCM mode?
Update: Just to be clear, a One-time pad cannot be done with a CSPRNG.
First of all, a terminology nit: please don't say "a One-time-pad generated by a CSPRNG"; a one-time pad must, by definition, be generated randomly, and an important part of its security proof is that it was generated randomly (and so an attacker cannot disqualify any potential pad, even if that attacker had infinite computational resources). Exclusive-or'ing a CSPRNG output with the plaintext to form the ciphertext is a stream cipher; while it is a perfectly usable primitive, it isn't the primitive known as OTP.
In addition, if we use a stream cipher, we usually don't generate the entire key stream on one side, and send that to the other. Instead, we usually send the key (initial CSPRNG state) from one side to the other; that drastically reduces the amount of keying material that needs to be sent, and is no less secure.
Now, with those nits done, the answer to your question (which is more secure, GCM or a secure stream cipher) depends on what you mean by "secure".
If by "secure", you mean privacy (that is, an eavesdropper cannot obtain any information of the encrypted message), well both GCM and secure stream ciphers are perfectly secure against real potential adversaries; on this score, they are even.
If by "secure", you mean integrity (that is, someone in the middle that can intercept messages, and inject modified versions cannot fool the receiver into accepting a message that the sender did not send), well, classic stream ciphers run into a problem. That's because stream ciphers are malleable; specifically, an attacker can flip a bit in the ciphertext. On decryption, the corresponding plaintext bit will be flipped (and thus an attacker who guesses what the plaintext is can modify the ciphertext so that it decrypts to whatever he wants). This doesn't work with GCM; if the attacker modifies the ciphertext in any way, the integrity check within GCM will fail, and so the receiver will reject the message. Yes, this means that an active attacker can cause messages to be rejected; an active attacker can do that in any case.
Now, there are standard constructions (such as a MAC) on top of the standard stream cipher apparatus which also provides integrity protection. So, if we ask CSPRNG+MAC vs GCM, well, there isn't a great deal of difference from a security standpoint (but there may be practical differences, such as "what happens if a message gets lost; do you need to handle that case?").
If you use a CSPRNG to generate the pad, you're not using a one-time-pad anymore by definition since the pad is no longer random, so the question as stated is incorrect with respect to terminology.
The advantage of using stream ciphers is that you no longer have the key distribution problem the OTP has, since your key is now only a few dozen bits long, and the key reuse problem is also negated, if addressed properly - perhaps with a KDF. Sure, you lose the attractive theoretical security properties, but what good is a cryptographic algorithm if you can't actually use it effectively in real life? Let's just say stream ciphers are an imperfect solution for an imperfect world.
Now, you suggest using the OS-provided CSPRNG to generate the pad - the issue with this approach is that it is essentially an OTP, but with all the disadvantages and no security proof, which is self-defeating:
On the other hand, AES in any streaming mode will work much better: your key is just 128-bit to 256-bit long, so you can distribute it fairly conveniently, and you can reuse your key for many messages using initialization vectors (so you probably only need to share the key once - unless, it gets compromised)
Do not forget to include a MAC if using a stream cipher - or even, if you must, an OTP - or use an authentication mode like GCM. The one-time-pad might provide perfect secrecy, but it gives you absolutely no guarantee on integrity. Anyone can intercept your ciphertext and flip bits here and there, possibly altering the intended message to their advantage if the format is somewhat known. Without a message authentication code, you have no way of knowing if the ciphertext was changed, and you are screwed.
Thats a Pseudo-One-Time Pad. A good CSPRNG need have only one attribute. Its output must be unpredictable to an attacker. And thats it. If it is truly unpredictable, then it must be random (otherwise it could be predicted). Note that many PRNG are completely predictable - for some simple schemes given a few bytes of output, the rest can be 100% predicted. However the seed value for the CSPRNG must have at least 128-bits of entropy. So you still need some truly random bits to get started!
Another and probably better alternative is to use a Blum-Blum-Shub generator. Now the unpredictability of the output is anchored to the known hard problem of integer factorisation.
It's much more secure to use AES (or some other well-understood cipher) in a well-described mode than to go construct some random number generator and pretend that it's a one-time pad. It's better not to lie to yourself.
If you use AES in counter mode, you're effectively using AES as a PRNG and then that as a pad, since you XOR the AES onto the plaintext. It's also well-understood.
GCM is a bit tetchy, there are plenty of ways to get it wrong. But nonetheless, yes, you're better off using GCM (which is a derivative of the basic counter mode) than where you're going.
