Encrypting RNG output Under the following premise:


I need to generate multiple symmetric keys;
I cannot be sure about the quality of local system RNG;
I already have a strong key K (generated by other means / elsewhere).


Does it make sense to encrypt the output of system RNG with K (or some derivation of it) with the purpose of strengthening generated keys. More generally, can I strengthen the output of the RNG using K? 

Clarifications:

Length - let's say that the entropy of K is 128 bit.
Number of keys - multiple, but not numerous (several or dozens, not more).

Second edit: 

More clarifications and comment:

Persistent (and secure, as long as the whole system is not compromised) storage is available, so a sequential IV can be implemented. 

I am starting to have doubts about the idea that RNG may be flaky while the system is still not compromised, but initially I assumed that RNG quality is not black and white and because it is easy to provide K, generated keys can be strengthened.

Apropos, I can deliver 256 bits K, so I can really just use it as seed for a PRNG and forget about all else. In any way, a compromise on the source of K is total falldown, so this starts to look like a straightforward option.
Don't even use the system RNG if you don't trust it but do trust K.


Use K to seed a secure PRNG; then generate keys from that RNG instead. (For example, ChaCha. Not RC4, because it's obsolete and insecure, but other secure stream ciphers work.)
Or use K with a key derivation function. If you don't need to follow standards then use HMAC with K for its key. Every time you need a symmetric key up to 512 bits long, increment a counter, HMAC the counter value, then take however many bits you need from the output.




Why?

You could encrypt the output of an RNG. Symmetric key encryption is supposed to produce ciphertext which is indistinguishable from a uniform random bit source. Encrypting a random or pseudorandom sequence isn't any better than encrypting some simple non-repeating sequence like a counter.

However, you could mess up the encryption by reusing nonces, using a block size that's too small, using a bad algorithm, or using a buggy implementation. I say don't use the system RNG if you don't trust it because encrypting its 
output is at best equal to the alternatives I listed. 

If your system RNG is biased or isn't seeded with enough entropy, then you have the problem of nonce reuse if you encrypt with a (not sufficiently) random IV. If you can prevent nonce reuse with a deterministic algorithm, then you can also prevent nonce reuse with secure PRNG or maintain a counter for the HMAC construct I mentioned.

You should be able to trust your operating system's secure RNG. But if you don't have access to one or you know it wasn't seeded with enough energy then that is reason to use something else.

You can't really make a better unpredictable non-deterministic RNG than what the OS can provide you. Userland attempts at entropy-gathering (non-deterministic) RNG algorithms don't have a good track record.

If you have a high entropy key, a secure algorithm, and ability to prevent nonce reuse, then PRNG/KDF output will be good.