- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jun 19 2021
The problem has been solved by me, but this and the problem are still very strange.
Ok i have seen a problem with a double check here
Jun 18 2021
ggp-agent has no support for U2F and it can't work with these key types. Given that Yubikeys also have proper keys (even eddsa) I doubt that we will implement support for ecdsa-sk OpenSSH feature any time soon,
Ok, I test this, this seem can be corrected 90% of all possible interference with another application on multi-applet smartcard in shared readers context. I left you the feel back when have tested… thank for the prompt response.
For the problem of external application switch, please test this:
diff --git a/scd/app-common.h b/scd/app-common.h index dffe1200d..d6e6f4c0a 100644 --- a/scd/app-common.h +++ b/scd/app-common.h @@ -194,6 +194,8 @@ struct app_ctx_s { void *pincb_arg); gpg_error_t (*with_keygrip) (app_t app, ctrl_t ctrl, int action, const char *keygrip_str, int capability); + gpg_error_t (*check_aid) (app_t app, ctrl_t ctrl, + const unsigned char *aid, size_t aidlen); } fnc; };
Here is the reference to GID specification:
https://docs.microsoft.com/en-us/previous-versions/windows/hardware/design/dn642100(v=vs.85)?redirectedfrom=MSDN
Let me add the tag "yubikey".
I think that it could be solved in different level, if I were the device manufacturer; And it would give users the best solution.
Jun 17 2021
Hello Mr. Koch,
That patch consists an ABI change. We might consider this for 1.10 but we can't do such a change in 1.9.
Please try the distributed binary version of gpgme from GnuPG or Gpg4win (which is usually a snapshot). As you might now, we don't support building on Windows - it may or may not work, we have no idea and don't suggest that.
Are you using Powershell or another non-standard shell? Which windows version are you using? Do you use default-key in gpg.conf? Do you have a smartcard inserted?
If something more user friendly is required, it could be possible for higher layer (SCDaemon's command handling) to check verification status beforehand, and do error recovery there.
I don't think we should do automatic error recovery from 6982 to retry decryption/signing, inside CMD_PSO (0x2A) operation.
Thanks for the report. Will soon be fixed.
I have tried the case 1 with log activated
Windows switches applet for signing Adobe Acrobat doc.
This is the log from agent - Say Bad NIP but he never tries to use the nip SCDaemon have tried to decrypt only.
gpg-agent[8496]: DBG: agent_put_cache '1//'.-1 (mode 6) requested ttl=-1
gpg-agent[8496]: DBG: chan_0x000001c0 <- S SERIALNO D2760001240103045343000000010000
gpg-agent[8496]: DBG: chan_0x000001c0 <- OK
gpg-agent[8496]: DBG: chan_0x000001c0 -> KEYINFO BBD342CA5B0F978DA17F2AD9F5A1E95FF50C129E
gpg-agent[8496]: DBG: chan_0x000001c0 <- S KEYINFO BBD342CA5B0F978DA17F2AD9F5A1E95FF50C129E T D2760001240103045343000000010000 OPENPGP.2
gpg-agent[8496]: DBG: chan_0x000001c0 <- OK
gpg-agent[8496]: DBG: chan_0x000001c0 -> SETDATA 4F0E7600C2C497A06288DF49B7EA1BC723E04FAC360D6D6C4F4DC1B48DEC13A53556229CDC4562E349C9B5E71365561A941761D1D2C709A16488903AA60925A7B103DEF6B6AE46814370AE815BFBE4A30EC443904C1D63E21ABF5B0B39B8484F3CB4235AEDA04F78F14308AE3DEF52309FB745BC65E3075D19C01C789C8F58931D957D7C26BE7DCEF6B880B362251246FA4E1A2830A13AD94635CC4CE14B0F253481F38C39BA5CC748FDF03F9D936B9C8DE6BF7E49AFF4BE3A84A4E4547FADD4C9F1634416641FF804F3503CC924098F1C4CAA908FD272737312A4D5BE59C644EE1633AA248DC996EF67BA5E087DB6312BD2014BFAFD62FD08C7D45E3AFD431C
gpg-agent[8496]: DBG: chan_0x000001c0 <- OK
gpg-agent[8496]: DBG: chan_0x000001c0 -> PKDECRYPT BBD342CA5B0F978DA17F2AD9F5A1E95FF50C129E
gpg-agent[8496]: DBG: chan_0x000001c0 <- ERR 100663383 Mauvais code personnel <SCD>
gpg-agent[8496]: smartcard decryption failed: Mauvais code personnel
gpg-agent[8496]: command 'PKDECRYPT' failed: Mauvais code personnel <SCD>
gpg-agent[8496]: DBG: chan_0x00000270 -> ERR 100663383 Mauvais code personnel <SCD>
Thank you.
Thank you.
I apply Diff1487 then Diff1488.
Jun 16 2021
Let me explain this problem more clearly. GPGME did not correctly receive and parse the output from gpgconf. Looking at the log file, EOF was generated when 4096 bits were read. So in engine info, although the path is correct, the identification of the version number is 1.0.0, and there is only gpgconf in the protocol, but there are no protocols such as gpg, assume, etc., which just means that gpgme does not correctly identify the output of gpgconf in this environment Information to find other protocols.
At the same time, I verified whether the output in gpgconf and the path of the related configuration are correct (whether there is a corresponding tool under the path), these are all right, which is very strange.
When a card sends 0x6982 in general rule is not really an error is a warning to say, your security environment was not correctly initialized.
This is true with almost applet. (PIV – GIDS – OPenPGP)
The instruction 0x2A to perform security operation return 0x6982 when pin is not authenticated or key is badly selected. This not decrement pin counter.
This is the log file output after the GPGME DEBUG environment variable is set.
You should run your test program with GPGME_DEBUG set. This gives some insight. The code you posted is too sparse to actually see what you are doing or want to do or what is the bug. Maybe it is better to ask the gnupg-devel ML?
Some ideas:
- the someflags thing will probably just be a reserved parameter
- If DATA is not NULL but an MD is set the sign function should fail
- Should ownership of MD be moved to the CTX?
In an email from @werner couple days back, I got a suggestion that we could use hashing tied to the context, rather than this one-shot call tied only to digests. I circled back this suggestion to Stephan and he confirmed that it should be fine from the FIPS point of view so I am posting the suggested API here too:
ctx = gcry_pk_new (someflags) md = gcry_md_open (...) gcry_ctx_set_md (md); gcry_pk_sign_ext (ctx, result, data, skey) [...] gcry_ctx_release (ctx);
OK. I think that the patch at SUSE is updated one which works.
As I understand correctly, this is a kind of very old patch, which intended to work around old libgcrypt limitation of RSA PSS.
Possible way would be: (for newer card/token of OpenPGPcard 3.4 or later) before crypto operations, we can ask card/token if authentication state is consistent to the one of scdaemon and if not reselect AID.
CC does not offer such an option as the GPL does.
I'd like to support your use case. Could you please tell me about: How can we distinguish normal failure of 6982 and unusual failure of other application interference which results 6982?
I think that {D1476} is still a sketch (not real code which works). I would guess an intended use, but it's good to have concrete example program which uses the feature being added.
FWIW, there is also this newer patch: https://dev.gnupg.org/differential/diff/1476/
and SUSE seems to already use a modified API:
https://sources.suse.com/SUSE:Maintenance:15118/libgcrypt.SUSE_SLE-15_Update/26a8df5f96d27d6abca7bd7ba9b0def0/libgcrypt-FIPS-RSA-DSA-ECDSA-hashing-operation.patch
Jun 15 2021
Our public key functions are stateless. For several reasons it would be good to have an option to keep some state (think pre-computations). Our gcry_ctx_t would be a perfect fit for this and it will allow us to join a pubkey function with for example a hash function.
Does the patch really work, or is it a sketch to describe the intended use?
@FloorVeil thanks for testing!
There is another report that it works in 3.1.16 again in
https://wald.intevation.org/forum/forum.php?thread_id=2044&forum_id=84&group_id=11
Not reproduced on 3.1.16.
I set the priority 'High' as Yubikey NEO is the last one with source code available, IIUC.
@kianga
Thanks for your log.
Jun 14 2021
I was just about to open a similar bug report, but I think this might be related. I’m also having trouble getting my Yubikey NEO to work with the latest update, however my log output looks different (see below) and this is on Windows (10 Pro, 21H1, build 19043.1055).