Hi Nathan, I tried to modify the examples/OCFSecure code to use certificates instead of hard-coded symmetric keys in the credentials. I think there is something missing beyond the setup of the creds in the json file. I tested my created certificates and keys via the provisioiningclient and sampleserver_mfg.
I reported the issue here https://lists.iotivity.org/g/iotivity-dev/message/10044. Could you comment on what actions are needed to setup the ciphersuite/PSK? Any pointers are appreciated. Khaled On Thu, Dec 6, 2018 at 2:45 AM Heldt-Sheller, Nathan < nathan.heldt-shel...@intel.com> wrote: > Thanks Max, > > > > Yes you’re right; my typo on that one thanks for catching J > > And yes, Certificate-based TLS handshake can require authentication by one > or both parties (that is, one or both present a Cert or Cert Chain to be > validated by the other). > > Thanks, > Nathan > > > > *From:* Max Kholmyansky [mailto:max...@gmail.com] > *Sent:* Wednesday, November 28, 2018 10:41 PM > *To:* Heldt-Sheller, Nathan <nathan.heldt-shel...@intel.com> > *Cc:* khaledi...@gmail.com; iotivity <iotivity-dev@lists.iotivity.org> > *Subject:* Re: [dev] Server to communicate via DTLS session with any > client? > > > > Hi Nathan > > > > Thanks for educating us. > > > > One point to clarify: when you say *"the reason the Client trusts the > Server" - *you actually meant that the *server *is making a decision *to > trust the client*, based on the technical explanation you provided? > > > > I understand that technically, same private key and sam certificate may be > reused between multiple clients connecting to the server, and all what the > server cares - is that each client can present the certificate and proof > the private key possession. > > > > Also, can you please clarify of TLS can work "in the reverse way", i.e. > requiring the server to present its certificate, and the client to verify > its validity. This is "inspired" by what I know about the public Internet > services: each organization running a secure web site has to obtain a > certificate, and web browsers (in client role) validate the certificates > presented by the server they connect to, but there is no requirement for a > browser (client) to carry any certificate. Can you please explain whether > this way is supported by IoTivity, and what are the considerations. > > > > Nathan, thanks again for your valuable feedback, and best regards. > > > > Max. > > > > > > > > > > On Wed, Nov 28, 2018 at 6:07 PM Heldt-Sheller, Nathan < > nathan.heldt-shel...@intel.com> wrote: > > Thanks Khaled, Max, > > > > Khaled is correct: the way to avoid needing a /cred entry for each Client > is to use asymmetric crypto (Certs in the IoTivity case). > > > A thorough explanation of asymmetric crypto is a bit much for an email but > I think this Q&A is pretty decent: > https://crypto.stackexchange.com/questions/32304/how-exactly-does-certificate-based-authentication-work. > There’s a lot more on the web if you search for “certificate based > handshake”. > > > > The (very) simplified version is that the Client presents a public > Identity certificate (also called End Entity Certificate) to the Server. > That EE Certificate contains a public key which corresponds to the private > key held by the Client, so that the Client can prove that it is the > rightful owner of the EE Cert, via asymmetric crypto operations. > > > > The Client’s EE Certificate is also signed by an entity called a > “Certificate Authority” or “CA”. The Server has a pre-installed > certificate called a “Root Certificate”. This is what allows the Server to > verify EE Certs issued by that CA. Using the public key in the Root > Certificate, the Client can verify the veracity of the EE Cert. > > > > So in the end, the reason the Client trusts the Server is that a) the > Client’s EE cert can be verified to have been issued by the CA, to the > owner of the corresponding private keys, and b) the Client can demonstrate > that it is the owner of those private keys. > > > > This doesn’t require a /cred entry for each Client, because the same Root > Certificate can be used to verify the veracity of many different Client > certificates. But the Server does need to have a the Root Cert installed > for the CA(s) that issued the Client cert. We call that Root Cert the > “Trust Anchor” because it is the last point in the dotted line of items > that form a logical chain of trustworthiness. > > > Hope that helps, > > Thanks, > Nathan > > > > *From:* iotivity-dev@lists.iotivity.org [mailto: > iotivity-dev@lists.iotivity.org] *On Behalf Of *Khaled Elsayed > *Sent:* Wednesday, November 28, 2018 6:10 AM > *To:* khaledieee <khaledi...@gmail.com> > *Cc:* max...@gmail.com; iotivity-dev <iotivity-dev@lists.iotivity.org> > *Subject:* Re: [dev] Server to communicate via DTLS session with any > client? > > > > Also, if you can clearly identify what is happening, please share your > findings. I had a look but still not totally clear about the exact > procedure. > > > > > > > > On Wed, Nov 28, 2018 at 4:07 PM Khaled Elsayed via Lists.Iotivity.Org > <khaledieee=gmail....@lists.iotivity.org> wrote: > > This can be done via certificates. You can find the example for the > provisionclient. I am still trying to figure out myself as it is not very > well documented. Quoting Nathan reply on my question sent last week or so. > > There is indeed an example of Certificate-based Client/Server > authentication in the IoTivity example “sampleserver_mfg”, which is in the > resource/csdk/securitiy/provisioning/sample folder. > > > > On Wed, Nov 28, 2018 at 2:56 PM Max <max...@gmail.com> wrote: > > > > Hi, > > > > I am looking for a technical advice on how a *secure UDP endpoint *("coaps") > exposed by IoTivity-powered server - may be accessed *from any > IoTivity-powered client*, without prior coordination between the client > and the server. > > > > This is similar to the idea that any browser in the world can access a web > site via SSL, while the server isn't blocking any particular browser from > the access. > > > > *[Note: this is a technology POC, not related to the OCF specification. So > the question is in the context of IoTivity library capabilities, not in the > context of the OCF security and compliance]* > > > > I would appreciate some advice from the people who understand how the DTLS > "handshake" in IoTivity works. > > > > Looking at the sample code... The "simpleclient" and "simpleserver" sample > solve the issue, via placing a shared "credential" into the security > configuration file. > > > > Below is the server configuration file. > > > > However, this isn't good for me, since the server needs a section per > specific "di" of the connecting client, while my goal is to allow DTLS > (secure) session for any client. > > > > I would appreciate ideas on how it can be done. > > > > Thanks in advance, > > > > Max. > > > > "cred": { > > "creds": [ > > { > > "credid": 1, > > "subjectuuid": "32323232-3232-3232-3232-323232323232", > > "credtype": 1, > > "period": "20150630T060000/20990920T220000", > > "privatedata": { > > "data": "AAAAAAAAAAAAAAAA", > > "encoding": "oic.sec.encoding.raw" > > } > > }, > > { > > "credid": 2, > > "subjectuuid": "31393139-3139-3139-3139-313931393139", > > "credtype": 1, > > "period": "20150630T060000/20990920T220000", > > "privatedata": { > > "data": "BBBBBBBBBBBBBBBB", > > "encoding": "oic.sec.encoding.raw" > > } > > } > > ], > > "rowneruuid": "32323232-3232-3232-3232-323232323232" > > } > > > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10046): https://lists.iotivity.org/g/iotivity-dev/message/10046 Mute This Topic: https://lists.iotivity.org/mt/28430313/21656 Group Owner: iotivity-dev+ow...@lists.iotivity.org Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
