error converting public key to pem

[tmountjr]

I should put in a caveat that I'm very much an end user here - my crypto knowledge is super basic. I've been working on integrating this library with a Nuxt site as a proof of concept and got it working locally; when I pushed it up onto a hosting platform, though, I found I was able to register credentials but not verify them. The specific error I get (Invalid key for curve: "Public key is not a point") seems to come from convertPublicKeyToPEM.js, specifically here:

const ecPEM = (0, jwk_to_pem_1.default)({
    kty: 'EC',
    // Specify curve as "P-256" from "p256"
    crv: convertCOSEtoPKCS_1.COSECRV[crv].replace('p', 'P-'),
    x: x.toString('base64'),
    y: y.toString('base64'),
});

I did some in-browser debugging and found that x and y are objects, not arrays, eg. instead of [129, 107, 105, 135, 73, 183] they're { 0: 129, 1: 107, 2: 105, 3: 135, 4: 73, 5: 183 }. When they're converted to strings, they get passed as '[object Object]' instead of what they probably should be, base64-encoded versions of an integer buffer. I did verify that the objects do have 32 sequentially numbered keys and if you do something like Buffer.from(Object.values(x)).toString('base64') you get something more like what I'd expect to see.

I realize there could be a thousand places along the way that could be breaking but I'm hoping someone can provide insight into why those values came through as objects instead of Buffers, and perhaps why that would only happen when running on something that isn't localhost.

[MasterKale]

Are you able to grab a full callstack? I imagine this is an error raised when you called verifyAuthenticationResponse()? If so, what is the value you're passing in for the credential's public key?

[tmountjr]

Sure thing! This does happen in verifyAuthenticationResponse() (or as a result of it).

The public key being stored is pQECAyYgASG4IGEwGDBhMQNhMhi7YTMYOmE0GM1hNRjDYTYOYTcYRWE4GEZhORhTYjEwGOxiMTEY5WIxMhhAYjEzGMFiMTQYc2IxNRgxYjE2GIdiMTcYXGIxOBhDYjE5GDxiMjAYTmIyMRRiMjIY4mIyMxhVYjI0GFRiMjUYzGIyNhhAYjI3GB9iMjgYKGIyORjUYjMwGPNiMzEY-CK4IGEwFWExGMVhMhjrYTMYI2E0GB5hNRhTYTYLYTcY2GE4GOJhORhTYjEwGMZiMTEYaWIxMhi_YjEzGP9iMTQYgGIxNRhDYjE2GI5iMTcYZmIxOBg5YjE5GJpiMjAYimIyMQJiMjIJYjIzFmIyNBgkYjI1GF5iMjYY8mIyNxhAYjI4GHRiMjkYlWIzMBhAYjMxGEQ. That's being passed to verifyAuthenticationResponse as this:

credential = {
  credId: '...',
  prevCounter: 0,
  publicKey: '<as above>'
}
credential.credentialPublicKey = base64url.toBuffer(credential.publicKey)
credential.credentialId = base64url.toBuffer(credential.credId)
credential.counter = credential.prevCounter

const verification = await fido2.verifyAuthenticationResponse({
  credential: {
    id,
    rawId,
    type,
    response: {
      clientDataJSON,
      authenticatorData,
      signature,
      userHandle
    }
  },
  expectedChallenge,
  expectedOrigin,
  expectedRPID,
  authenticator: credential
})

i'm having some internet issues deploying a new version of my code that would spit out the entire object being passed to verifyAuthenticationResponse so please let me know if you need more or different actual data and I'll try to get that for you. Thanks!

[tmountjr]

And as soon as I wrote that it deployed and I got the complete object being sent: https://gist.github.com/tmountjr/239deb0da274391b4da854c5e9a5466e

[tmountjr]

Did some additional troubleshooting. When I said earlier it worked locally, that wasn't precisely correct. It works locally running npx nuxt (starting the framework in dev mode) but not using npx nuxt build --standalone && npx nuxt start (builds the framework - using webpack, which might be key - and runs it in production mode). I had a problem with another library and webpack 4...I wonder if maybe webpack is screwing something up? One thing I might try is excluding this from webpack and seeing what happens.

[tmountjr]

Huh, interesting. So I'm looking at the source for that particular file: https://github.com/MasterKale/SimpleWebAuthn/blob/master/packages/server/src/helpers/convertPublicKeyToPEM.ts

The lines there are:

const ecPEM = jwkToPem({
  kty: 'EC',
  // Specify curve as "P-256" from "p256"
  crv: COSECRV[crv as number].replace('p', 'P-'),
  x: (x as Buffer).toString('base64'),
  y: (y as Buffer).toString('base64'),
});

But the dist version I have downloaded completely drops the as Buffer part. Doesn't really explain why it works when i'm not using webpack unless webpack really mangled it. I did try excluding that particular package from webpack to no avail.

[tmountjr]

I took a closer look at the method when running without webpack - the types of x and y in this case is are both Uint8Array(32) rather than a plain object.

[MasterKale]

Hmm, you mentioned Nuxt. Is verifyAuthenticationResponse() being executed in the browser? Because Buffer is a Node-specific type, and is not supported in browsers. Uint8Array is what Buffers are under the hood, but @simplewebauthn/server methods expect to be run in a Node-like runtime with Buffer support, which does not include browsers. 🤔

[MasterKale]

Does AWS lambda offer Node API's like Buffer? The biggest blocker I identified to @simplewebauthn/server being usable in non-Node environments like CloudFlare workers, Bun, Deno, etc... is the extensive use of Node's Buffer. I'm curious how you might have overcome this (given that I'm not sure what kind of JS runtime environment that lambdas runs code in)

[tmountjr]

I'm an engineer at and also using Edgio (https://edg.io) and for the moment at least our lambdas are running Node 14, and whether it's the full version or something stripped down, it does implement the Buffer class. In the example repo I made, I'm serializing to Firebase to avoid the need for persistent in-memory storage and I ran into an issue because when you post a Buffer up to Firebase as a JSON object you end up with something like this:

{
  theObject: {
    data: [ 1, 2, 3, ... ],
    type: "Buffer"
  }
}

So I'm running Buffer.from(theObject.data) when I bring it back down from Firebase and everything works just fine. I've read that Deno's Buffer implementation currently needs to be imported from the standard io library, but that it's going to be first-class eventually. That may suggest some sort of portability, though - even if there was some sort of abstraction layer that used a simple array as the underlying storage mechanism.

[MasterKale]

Interesting. I have #268 open to try and open up support for non-Node runtimes, if you have any insights that might help me identify a path forward I'd be grateful if you shared 😇

Right now I'm debating between trying to create and use a Buffer polyfill, or rewrite everything to use Uint8Array instead. The polyfill might have to be the way forward if third-party libraries I use assume Node, but the "correct" solution is probably to use Uint8Array since it's in the broader "Web API" that things like Deno target 🤔

[tmountjr]

I haven't built/deployed Deno packages before so I'm not sure if that means a single build that works on both platforms or maintaining two forks of the same basic code - but refactoring to use an array feels like less work in the long run. That might also simplify the architecture of the entire package - I mean, the problem I ran into was using something that was tagged as "serverside" in a browser, and the reason it didn't work was because Buffer is a Node thing that doesn't exist in a browser context. That may not be the only thing (eg, some crypto modules maybe?) but I wonder if switching to a typed array that exists in both contexts would let you manage the entire lifecycle on the client-side...

[MasterKale]

I haven't built/deployed Deno packages before so I'm not sure if that means a single build that works on both platforms or maintaining two forks of the same basic code

My goal is to publish a single package that can work in all kinds of environments. I focused on Node when I started SimpleWebAuthn because there weren't a lot of alternatives back then, but then they started sprouting like weeds and I'm thinking it's in the project's best long-term interests to become runtime agnostic.

That might also simplify the architecture of the entire package - I mean, the problem I ran into was using something that was tagged as "serverside" in a browser

But to be fair to you, as I understand it you weren't trying to run it in a browser context. Rather it was Next doing so as part of its build process which I think is related to how it tries to pre-render pages for caching. It was a similar issue I'd run into with Gatsby in the past, back when SSR frameworks like it were fairly novel.

That may not be the only thing (eg, some crypto modules maybe?) but I wonder if switching to a typed array that exists in both contexts would let you manage the entire lifecycle on the client-side...

I'd characterize the goal as "managing the entire lifecycle in a Web-like environment." Running an RP entirely in client-side code will never be an acceptable way to host one because nothing is secret there. Rather it'd be focusing on supporting execution in privileged environments, like cloud workers, that are "backend-like" but in a runtime that more closely mirrors a web browser (because they're using the same V8/SpiderMonkey/etc... as browsers use, just in The Cloud)

[tmountjr]

Ran into another weird probably-just-me blocker but I figured I'd toss it out here just in case. Webpack (4, if it matters) seems to be doing something funky. In my Vue component I'm using import { startRegistration } from '@simplewebauthn/browser which is fine, but when the project compiles, I get this:

Must use import to load ES Module: /path/to/project/node_modules/@simplewebauthn/browser/dist/bundle/index.js

The stack trace shows a bunch of webpack stuff and I can only imagine that webpack is trying to convert this into a CommonJS format for some reason. :sigh: Nothing is ever simple, huh...

[tmountjr]

Fixed that by making sure that webpack transpiled the @simplewebauthn/browser package. But now I'm getting window is not defined when using browserSupportsWebauthn which i think i read about somewhere else...

[tmountjr]

Oh, interesting. I'll have to see if I can switch it up to some sort of middleware context instead. Weird that it still works though in dev mode though...

…

On Wed, Sep 21, 2022, 15:36 Matthew Miller ***@***.***> wrote: Hmm, you mentioned Nuxt. Is verifyAuthenticationResponse() being executed in the browser? Because Buffer is a *Node-specific* type, and is not supported in browsers. Uint8Array is what Buffers are under the hood, but ***@***.***/server* methods expect to be run in a Node-like runtime with Buffer support, which does not include browsers. 🤔 — Reply to this email directly, view it on GitHub <#272 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJF3W52JCZZLIJHKT5TAF3V7NPTZANCNFSM6AAAAAAQSCD77I> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[tmountjr]

Finally got it up and running with Nuxt! I'm taking advantage of my platform's ability to fire up a serverless environment and using Firebase as both a user repository (Firebase Auth) and as a metadata store about those users (Realtime DB). Source code available at https://github.com/tmountjr/webauthn-firebase-nuxt. It's deployed at https://webauthn.tommount.net.

Nuxt has the ability to run what it calls "server middleware" - basically running an express server in the background that handles requests exclusively serverside. I could also have those auth routes handled by Nuxt directly rather than shortcutting things with a platform that does that maybe slightly more reliably, but that's a project for later.

I think the original intent of this discussion - "why doesn't the server code work in a browser?" - has been answered, and there's a proof-of-concept how something like this integrates with a complete jamstack environment, so I'm fine with this being closed out. I know the discussion did veer a little more towards how to make a more universal set of packages so I'm also happy to keep it open and discuss that too. :)