Generally, you have a few goals:
- Keep the data secure during transport
- Prevent leakage during the transmission from system to output and back to system
- Limit possible exposure, even of the encrypted value after the transmission.
- Ensure that the person who is transporting the secret cannot obtain or abscond with it
If you are moving a symmetric key or copying a private key, you may want to set up pub/private keys between the two air gaps as well if you are doing this through some manual mechanism like copying to a flash drive, even if the flash drive itself it encrypted, so that only in the presence of the private key can the secret being based be decrypted. If you are just moving public keys, those may not need the same level of security.
Let's look at some risks in the QR code scenario. You need to generate the QR code with some program and then print it. You need to ensure that the printer is secured (even if the printer is in the air gap, can someone later check the memory of the printer, force a reprint of the last page, etc). You also have the risk that the value will be stored in an insecure temporary file or print cache somewhere on the disk which can later be retrieved. Now when the person with the QR code is moving it between the sites, can they take a photo of it? Did they ensure the print out is in a secure, possibly tamper evident photo, so we can ensure that they do not switch it with a malicious print out in the process and no video camera between the air gap steal the photo? At the other air gap, how is the QR code being read back in? Is the camera/scanner secure, is the program reading in the QR code going to leave a trace in a temp file? Do you need to store the QR code value in a temp file to be read in to the encrypted storage or HSM?
I would say QR codes are likely a bad choice for this. You would ideally want something that is providing cryptographic security, tamper resistant (to human or a device which intercepts or copies in the air), and tamper evidence between the two sites.
Some type of HSM would be a good choice. Beyond that a write-once CD/DVD may be a good option with proper public/private key encryption because you can use trusted hardware on both sides and then destroy the disc cheaply and easily. However, you will have trouble detecting unauthorized duplication. A USB device is much more likely to be infected with malware and its harder to detect or block (check out the presentation from this year's blackhat). With any method, you may want to split the key and require two couriers so that collusion is required to leak the ciphertext. A nice feature would be if you had a device that would only write back the value once and then not write it again (self destruct after write) so if there is a leak you could not prevent, you could at least detect it.
(As noted in my comment, I am still looking to see if I can find those devices; the ones I found going back were for specific proprietary military systems).
You may be interested in some of the NIST SP-800 guidelines related to this:
Section 6.6.1 Key Transport of Draft SP 800-152 addresses key transport, Section 6.6.1 of SP 800-130, is also very similar.
SP 800-57 Part 2 has some scenarios showing key management, and gets pretty technical. Even more technical details are addressed in FIPS PUB 140-2