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" <g...@mira.net> 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 <step...@perthprojects.com> > 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 <g...@mira.net> 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* >>> >> >> >
