OpenPGP spec, Section 4.3.3.5). The second-highest bit in the first byte is 1 if the YubiKey supports the GET CHALLENGE command, which is what gpg-connect-agent seems to use when you run scd random XX. The third and fourth byte encode the maximum length supported for such a request.
I extracted the extended capabilities bytes for my YK 4n and YK Neo:
Code:
[0xF0, 0x00, 0x00, 0xFF, 0x04, 0xC0, 0x00, 0xFF, 0x00, 0xFF] (YK Neo)
[0x3C, 0x00, 0x00, 0x00, 0x04, 0xC0, 0x00, 0xFF, 0x00, 0xFF] (YK 4n)
As you can see, the second-highest bit of the first byte is set for the YK Neo and it supports GET CHALLENGE requests for up to 255 bytes at a time. The YK 4n (and most likely the 4 as well) announces that it does not support GET CHALLENGE. That means that it is realistically impossible to retrieve random numbers from the OpenPGP applet on the YK 4, barring crazy techniques such as harvesting entropy from generated keys.
An alternative could be to use the PIV applet, which can generate random challenges via the GENERAL AUTHENTICATE command (PIV spec, Section A.1). The downside is that you can apparently only generate 8 random bytes per request and may have to have PIV certificates present on the YK (not sure about the latter, as I can't test it atm).
Example invocation of piv-tool (the last 8 bytes of the response are random):
Code:
$ piv-tool --send-apdu 00:87:00:9B:04:7C:02:81:00:00
Using reader with a card: Yubico Yubikey 4 OTP+U2F+CCID 00 00
Sending: 00 87 00 9B 04 7C 02 81 00 00
Received (SW1=0x90, SW2=0x00):
7C 0A 81 08 9A 8B F2 A1 5F 54 58 72 |......._TXr
Statistics: Posted by fhenneke — Fri Dec 29, 2017 11:58 am
]]>
