Re: X509 certificate and trust
> > I don't think Silverlight supports such authentication. > Yeah, it looks that way. Most of the important certificate classes and methods are stripped out of the mini CLR. I eventually decided that the phone must perform a one-off registration, but I'm still not sure how the phone can identify itself to the service in an unforgeable way. Perhaps a signed time-stamped token from the server which can only be used for a single "session" (but the details are still hazy) -- *Greg*
Re: X509 certificate and trust
Greg What it sounds like you are being asked to do is certificate based authentication. This is something that cannot be forged, unlike a 'magic number'. The server can verify the validity of the cert and identify the client. You might have individual certs to identify a user or device. I've done this before for a web app on WinMo 6 where the user's own Active Directory cert is loaded on the device and IIS requires the cert as part of the type of authN. It avoids the user having to type in creds on a PDA but the servers knows who the user is. The pfx file will contain the certificate (plus, if necessary, root CA cert and any intermediate certs needed to be loaded on the client to complete the chain to be trusted). I don't think Silverlight supports such authentication. HTH On 25 Nov 2014 21:21, "Greg Keogh" wrote: > Howdy, I've been thinking about this overnight and have had no Eureka! > moment. I do have the factory ID of the phone, but I think registering the > IDs on the server would be a bother (in any case, a fake client could send > any ID it wanted to fool the server). > > The client and server both have the same confidential company certificate, > but I don't know how I can leverage this. The client could send the server > some secret data out of the cert, but it's just a number, any magic/secret > number could be shared, which is childish. > > So I remain puzzled about how an arbitrary phone can prove to the service > that it's calling via trusted client software without human entry of a PIN > or password. > > The phone does have a config screen, so perhaps the human operator could > be instructed to put in a 4 digit "hash" of the phone ID, which can only be > computed and verified on the server. This would require a one-time setup > process, but it might be acceptable in the form of a "registration screen" > on the phone. > > *Greg K* > > > On 25 November 2014 at 23:55, Stephen Price > wrote: > >> And then I read your email a second time and notice you said Silverlight >> PHONE app. Perhaps you could use something similar... but as it's not >> hosted on a web server, but instead its on the phone that might not work. >> Perhaps a call to a server with a login where a key is given out for that >> session? Or something that is harder to fake, like a phone ID (can you set >> up a list of authorised devices on server or is it a public facing app >> where anyone could be connecting?) >> >> On Tue, Nov 25, 2014 at 8:06 PM, Greg Keogh wrote: >> >>> Folks, I have a Silverlight Phone app that talks to a WCF service. The >>> spec says that phones must *prove* to the service that they are >>> legitimate and trusted. I figure therefore that I will stuff something in >>> the message headers of each call that can't be forged to prove a phone has >>> legitimate client software ... but what? >>> >>> The spec is vague and does not specify any kind of "login" method or >>> handshake to establish trust. >>> >>> To confuse matters, I've been given a pair of X509 certificates (as cer >>> and pfx files) without any hint about what to do with them. So I've been >>> reading about X509's for hours, but I can't figure out if they're of any >>> help in this situation or not. All the sample code I've found using >>> certificates is for the full CLR and not for the Silverlight CLR where many >>> classes are smaller or missing. I can't figure out how to use X509s for >>> solving my problem (if they are of any use). >>> >>> Any suggestions from crypto protocol boffins out there? >>> >>> *Greg K* >>> >> >> >
Re: X509 certificate and trust
Howdy, I've been thinking about this overnight and have had no Eureka! moment. I do have the factory ID of the phone, but I think registering the IDs on the server would be a bother (in any case, a fake client could send any ID it wanted to fool the server). The client and server both have the same confidential company certificate, but I don't know how I can leverage this. The client could send the server some secret data out of the cert, but it's just a number, any magic/secret number could be shared, which is childish. So I remain puzzled about how an arbitrary phone can prove to the service that it's calling via trusted client software without human entry of a PIN or password. The phone does have a config screen, so perhaps the human operator could be instructed to put in a 4 digit "hash" of the phone ID, which can only be computed and verified on the server. This would require a one-time setup process, but it might be acceptable in the form of a "registration screen" on the phone. *Greg K* On 25 November 2014 at 23:55, Stephen Price wrote: > And then I read your email a second time and notice you said Silverlight > PHONE app. Perhaps you could use something similar... but as it's not > hosted on a web server, but instead its on the phone that might not work. > Perhaps a call to a server with a login where a key is given out for that > session? Or something that is harder to fake, like a phone ID (can you set > up a list of authorised devices on server or is it a public facing app > where anyone could be connecting?) > > On Tue, Nov 25, 2014 at 8:06 PM, Greg Keogh wrote: > >> Folks, I have a Silverlight Phone app that talks to a WCF service. The >> spec says that phones must *prove* to the service that they are >> legitimate and trusted. I figure therefore that I will stuff something in >> the message headers of each call that can't be forged to prove a phone has >> legitimate client software ... but what? >> >> The spec is vague and does not specify any kind of "login" method or >> handshake to establish trust. >> >> To confuse matters, I've been given a pair of X509 certificates (as cer >> and pfx files) without any hint about what to do with them. So I've been >> reading about X509's for hours, but I can't figure out if they're of any >> help in this situation or not. All the sample code I've found using >> certificates is for the full CLR and not for the Silverlight CLR where many >> classes are smaller or missing. I can't figure out how to use X509s for >> solving my problem (if they are of any use). >> >> Any suggestions from crypto protocol boffins out there? >> >> *Greg K* >> > >
Re: X509 certificate and trust
And then I read your email a second time and notice you said Silverlight PHONE app. Perhaps you could use something similar... but as it's not hosted on a web server, but instead its on the phone that might not work. Perhaps a call to a server with a login where a key is given out for that session? Or something that is harder to fake, like a phone ID (can you set up a list of authorised devices on server or is it a public facing app where anyone could be connecting?) On Tue, Nov 25, 2014 at 8:06 PM, Greg Keogh wrote: > Folks, I have a Silverlight Phone app that talks to a WCF service. The > spec says that phones must *prove* to the service that they are > legitimate and trusted. I figure therefore that I will stuff something in > the message headers of each call that can't be forged to prove a phone has > legitimate client software ... but what? > > The spec is vague and does not specify any kind of "login" method or > handshake to establish trust. > > To confuse matters, I've been given a pair of X509 certificates (as cer > and pfx files) without any hint about what to do with them. So I've been > reading about X509's for hours, but I can't figure out if they're of any > help in this situation or not. All the sample code I've found using > certificates is for the full CLR and not for the Silverlight CLR where many > classes are smaller or missing. I can't figure out how to use X509s for > solving my problem (if they are of any use). > > Any suggestions from crypto protocol boffins out there? > > *Greg K* >
Re: X509 certificate and trust
Hey Greg In the past I've handed the Silverlight xap file something random (lets call it a key to get in) in the init parameters. The client then gives that back to the WCF service as proof that the Xap file was launched by a known web server. You could renew it periodically or let it run for that session and next time it runs it gets a different key. I'm sure there are other ways but this one skips the whole log in requirement. You could also use standard web authentication before they get to the Silverlight page too so the user would have to log in before getting a key/Xap. YMMV cheers Stephen p.s. you could also give back the spec (for more clarification) and tell them its too vague, but I know that that's not always an option. On Tue, Nov 25, 2014 at 8:06 PM, Greg Keogh wrote: > Folks, I have a Silverlight Phone app that talks to a WCF service. The > spec says that phones must *prove* to the service that they are > legitimate and trusted. I figure therefore that I will stuff something in > the message headers of each call that can't be forged to prove a phone has > legitimate client software ... but what? > > The spec is vague and does not specify any kind of "login" method or > handshake to establish trust. > > To confuse matters, I've been given a pair of X509 certificates (as cer > and pfx files) without any hint about what to do with them. So I've been > reading about X509's for hours, but I can't figure out if they're of any > help in this situation or not. All the sample code I've found using > certificates is for the full CLR and not for the Silverlight CLR where many > classes are smaller or missing. I can't figure out how to use X509s for > solving my problem (if they are of any use). > > Any suggestions from crypto protocol boffins out there? > > *Greg K* >
