Can Pseudorandom values be used as secure keys?

Question

I want to derive $n$ keys from a master key.

I pick a master key $mk$ and use pseudo-random function (PRF) to generate $n$ pseudo-random values, $v_i=PRF(mk,i)$ where $1\leq i \leq n$. Next, I use key derivation function to generate $n$ keys: $k_i=KDF(v_i)$, where $1\leq i \leq n$. Note that key derivation must be deterministic.

Question 1: Is above scheme a secure way of generating $n$ keys?

Question 2: Can we consider values $v_i$ as secure cryptographic keys?

Answer 1

Yes and yes, as mentioned in the comments.

It is worth noting that Bitcoin wallets use a scheme similar to this in BIP32, a method of creating n various EC keypairs from a single seed deterministically:

https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki

EDIT: This answer only holds true if 𝑃𝑅𝐹 is a CSPRNG. (This application is sort of why the definition for CSPRNG exists.)

Answer 2

If your protocol were secure with independent uniform random choices for the $v_i$, then it can't be much less secure with $v_i = \mathit{PRF}(\mathit{mk}, i)$ for uniform random $\mathit{mk}$, as long as you never use $\mathit{PRF}(\mathit{mk}, i)$ for any other purpose—the only additional advantage an adversary can get in breaking the system with the PRF is the best possible advantage at distinguishing the PRF, which, for a good PRF, is negligible. This is the essential point of a PRF!

The term ‘KDF’ sometimes covers two steps, as in HKDF-Extract and HKDF-Expand:

1. extracting a short uniform string from a high-entropy but possibly nonuniform string (like a DH shared secret), sometimes with a salt to mitigate multi-target attacks, and
2. expanding a short uniform string by a PRF into many effectively independent keys with structured inputs (what you called $i$) to avoid collisions.

If you already have a short uniform string, you can safely skip the extraction step, and what you are left with is just a PRF! It doesn't hurt to do another extraction step afterward—hash the PRF output again as you described—but there's no need.