Yes indeed the ACL is ok in cbor. What I thought was that I could dynamically change the permissions by changing the dat file somehow.
On Fri, Jan 5, 2018, 16:43 Nash, George <george.n...@intel.com> wrote: > I don’t think the ACL file is encrypted it is CBOR. The fastest way to > find the contents of the file is to copy it off the Android device and open > it in a HEX editor. Copy the bites to cbor.me web site and use the web > site to convert it to JSON so it is human readable. > > > > Then you can verify the contents of the .dat file. See if it is indeed > doing what you think it is doing. Is the file you are passing in getting > over written? Do the ACLs look good? Etc. > > > > Everything security releated filters down to the C code that is doing the > actual work. So it can be helpful to understand how something is done in C > even if your primary language is Java. > > > > *From:* Arthur Barros Lapprand [mailto:a...@cin.ufpe.br] > *Sent:* Friday, January 5, 2018 11:34 AM > *To:* Nash, George <george.n...@intel.com> > *Cc:* Rami Alshafi <ralsh...@vtmgroup.com>; iotivity < > iotivity-dev@lists.iotivity.org> > > > *Subject:* Re: [dev] FW: Android SECURED mode > > > > Hi George, > > Sorry for the long wait, I've been quite sick. But here we go. As you said > the strings are mapped internally in the JNI code. Does this mean there's > no current way in Android to use an encrypted ACL dat file? Or is it not > necessary? The local ACL is loaded on configure but after that I haven't > checked how the SVR works with it. I'm planning on looking into the SVR DB > code to see if that helps me insert an ACE. > > Regards, > > A. Lapprand > > > > Em ter, 2 de jan de 2018 às 14:55, Nash, George <george.n...@intel.com> > escreveu: > > A. Lapprand, > > > > The Java code takes the ACL configuration file and the introspection as > parameters when configuring the OcPlatform. The strings are mapped > internally in the JNI code to an fopen() function. If you are working on > Android the most important thing is to make sure the files are installed in > a location that they can be opened and that location is properly specified > in the OcPlatform configuration. > > > > George Nash > > > > *From:* iotivity-dev-boun...@lists.iotivity.org [mailto: > iotivity-dev-boun...@lists.iotivity.org] *On Behalf Of *Arthur Barros > Lapprand > *Sent:* Wednesday, December 27, 2017 8:43 AM > *To:* Rami Alshafi <ralsh...@vtmgroup.com> > *Cc:* iotivity <iotivity-dev@lists.iotivity.org> > > > *Subject:* Re: [dev] FW: Android SECURED mode > > > > Hi Rami, > > I have looked the fopen() functions and I'm currently in doubt on how to > do it in Java since I'm only passing the ACL dat file when configuring > OcPlatform. Also, is your sample released in IoTivity 1.3.1 (couldn't find > it) or is it for a future update? > > Thank you, > > A. Lapprand > > > > Em ter, 26 de dez de 2017 às 22:15, Arthur Barros Lapprand < > a...@cin.ufpe.br> escreveu: > > Ohhhhh, I see! That should help me understand the issue. Will look into it! > > Thank you, > A. Lapprand > > > > Em Ter, 26 de dez de 2017 22:06, Rami Alshafi <ralsh...@vtmgroup.com> > escreveu: > > Nope! Device_properties and introspection are completely separate things > and not related. You do not need the introspection file for solving your > error and the Unauthorized_req issue. > > Thanks, > > -Rami > > > > *From:* Arthur Barros Lapprand [mailto:a...@cin.ufpe.br] > *Sent:* Tuesday, December 26, 2017 4:48 PM > *To:* Rami Alshafi <ralsh...@vtmgroup.com> > *Cc:* Morrow, Joseph L <joseph.l.mor...@intel.com>; Tonny Tzeng < > tonny.tz...@gmail.com>; iotivity <iotivity-dev@lists.iotivity.org>; > Matthews, Michael L <michael.l.matth...@intel.com> > > > *Subject:* Re: [dev] FW: Android SECURED mode > > > > Hi Rami, > > Yes indeed, I'll have a look at it and try to implement as soon as I can. > If the device properties file is the same as the introspection file Joseph > mentioned before, which I believe it is, then all the better! For now I > need some sleep. Thank you all and be back soon! > > Best regards, > > A. Lapprand > > > > 2017-12-26 21:16 GMT-03:00 Rami Alshafi <ralsh...@vtmgroup.com>: > > Arthur, > > I think I know what’s up!! This seems to be a symptom of a problem I had > before! It is related to the device properties dat file. > > If this is the case then what is happening is your server and client dat > files are perfectly fine but your fopen() function in the server and/or > client expects to see the server/client svr file but instead it gets the > device properties dat file and thinks it is a corrupted server/client svr > file and then it will over write the good server/client svr file with > another that is no good either. > > > > If this is the case, then reference the ServerFOpen(const char *path, > const char *mode) function in my server app and the ClientFOpen(const char > *file, const char *mode) function in my client app and implement them in > your apps. Next, run your server and it will generate a > device_properties.dat file. Copy that file to where the client app is > running from and then run your client application. > > > > Let me know if that fixes your problem > > Thanks, > > -Rami > > *From:* Arthur Barros Lapprand [mailto:a...@cin.ufpe.br] > *Sent:* Tuesday, December 26, 2017 4:02 PM > *To:* Morrow, Joseph L <joseph.l.mor...@intel.com> > *Cc:* Tonny Tzeng <tonny.tz...@gmail.com>; iotivity < > iotivity-dev@lists.iotivity.org>; Rami Alshafi <ralsh...@vtmgroup.com>; > Matthews, Michael L <michael.l.matth...@intel.com> > > > *Subject:* Re: [dev] FW: Android SECURED mode > > > > Hi Joseph (or Joey, I don't know which), > > I can see the ACL I set before converting but I'm far from seeing the > Device ID I mentioned above (5fd82524-0f91-050b-bc3c-2707d57ac132). Perhaps > I'm missing something? And by CBOR payload does that imply the byte array > received in the callback? > > Regards, > > A. Lapprand > > > > 2017-12-26 17:19 GMT-03:00 Morrow, Joseph L <joseph.l.mor...@intel.com>: > > Hi Arthur, > > > > I don’t know if you’re running on Linux or on Windows. But in any case, > from a Linux Terminal or Cygwin Terminal (eg. Git Bash on Windows), you can > pass the following command to retrieve the contents of your .dat file. > > > > xxd -p [arthur].dat > > > > Then copy the hex contents to your clipboard. Paste it in the right dialog > at www.cbor.me > <https://urlf.duocircle.io/?url=http%3A%2F%2Fwww.cbor.me&id=31d5&rcpt=ralsh...@vtmgroup.com&tss=1514332948&msgid=38e74fda-ea99-11e7-8127-5bff9d28ac92&html=1&h=1b1d6909>. > Then click on the Left Arrow to the left of the word “Bytes” at the top of > the page. > > > > The left dialog will get populated. Copy everything in the quotes (where > ‘…’) is the hex contents of CBOR content within CBOR key ‘doxm': "h’…’” > > > > Empty the right dialog (ctrl+a + backspace), Paste the doxm contents and > you should see the Device ID you mentioned below in this body of DOXM. > > > > Likewise, you should be able to see the configurations you set for ACL > before you converted with json2cbor. Just be sure to notice that there is > CBOR hex within the CBOR payload, so you will have to convert those > sub-components with “cbor.me > <https://urlf.duocircle.io/?url=http%3A%2F%2Fcbor.me&id=31d5&rcpt=ralsh...@vtmgroup.com&tss=1514332948&msgid=38e74fda-ea99-11e7-8127-5bff9d28ac92&html=1&h=0235c6ff>” > as well. > > > > Thanks, > > > > Joey Morrow > > > > *From: *Arthur Barros Lapprand <a...@cin.ufpe.br> > *Date: *Tuesday, December 26, 2017 at 10:48 AM > > > *To: *Joseph L Morrow <joseph.l.mor...@intel.com> > *Cc: *Tonny Tzeng <tonny.tz...@gmail.com>, iotivity < > iotivity-dev@lists.iotivity.org>, Rami Alshafi <ralsh...@vtmgroup.com>, > "Matthews, Michael L" <michael.l.matth...@intel.com> > *Subject: *Re: [dev] FW: Android SECURED mode > > > > Hi Joseph, > > I couldn't find the error code but I did look into the error=ERROR flag > which is described as a "generic error". Precisely, this one: > "org.iotivity.base.OcException: stack error in onGetCallback ERROR". I > don't know about the [introspection].dat file but I did look at that > server_fopen() code before. I'm did convert the UUID to a string but it's > not really human readable, probably because the OcPlatform.getDeviceId() is > returning a random generated ID. On my client app, when the > OnResourceFound() callback is triggered and I print the > ocResource.getServerId() it comes out as > "5fd82524-0f91-050b-bc3c-2707d57ac132", which is nothing like the ID in the > ACL. I may be confused about that since I don't know if the ServerId should > be the same. Nevertheless, I'm sending the .dat files and .json ACL just in > case someone want to have a look and possibly find something wrong. Oh, and > about the introspection file, do I need to set it up if I want the ACL to > work? > > Thank you, > > A. Lapprand > > Em ter, 26 de dez de 2017 às 15:11, Morrow, Joseph L < > joseph.l.mor...@intel.com> escreveu: > > Hi Arthur, > > > > Quick Tip: Most of the errors are OCStackErrors. If you have a non > HTTP-looking error (eg. 404, 501, …4.04, 5.01, …), then it is likely > defined in octypes.h. Please compare to the enumeration found in > <iotivity>/resource/csdk/include/octypes.h. > > > > A common error is ’46’ which means “Unauthorized.” This has occurred to me > in many cases: > > > > - IoTivity has overwritten your SVR *.dat file and therefore corrupted > all of your configurations > > > - This can happen if you’re providing your own “[arthurs_cbor].dat" > file but forget about the [introspection].dat file. Please verify you > use a > similar if-check as found in > <iotivity>/resource/examples/lightserver.cpp:server_fopen(). > - This can also happen if for some reason your *.dat file doesn’t > follow correct CBOR format or if something in there isn’t the right > format. > Perhaps your device ID is wrong, for instance. To verify the SVR was > loaded > correctly, please see that your Device ID is as you’ve defined it by > calling (C++ SDK). You can either debug or convert the UUID to a string > and > print it out. > > “ > > OCUUIdentity id; > > OC::OCPlatform::getDeviceId(&id); > > “ > > - The ACLs in your config are set up correctly. I will defer to > someone else for that info. > - If any symmetric keys (ie. Raw) or pins are being used in your SVR > file, make sure they match on both sides (server & client). > > Thanks, > > > > Joey Morrow > > > > *From: *Arthur Barros Lapprand <a...@cin.ufpe.br> > *Date: *Tuesday, December 26, 2017 at 5:04 AM > *To: *Joseph L Morrow <joseph.l.mor...@intel.com> > *Cc: *Tonny Tzeng <tonny.tz...@gmail.com>, iotivity < > iotivity-dev@lists.iotivity.org>, Rami Alshafi <ralsh...@vtmgroup.com>, > "Matthews, Michael L" <michael.l.matth...@intel.com> > > > *Subject: *Re: [dev] FW: Android SECURED mode > > > > Hi Joseph, > > I have done as you described and it indeed changed the situation. The > error which before had the UNAUTHORIZED_REQ flag now has the ERROR flag. I > don't really know what this flag means but I'm searching it. > > Regards, > > A. Lapprand > > > > Em seg, 25 de dez de 2017 às 14:38, Morrow, Joseph L < > joseph.l.mor...@intel.com> escreveu: > > Hi Arthur, > > > > My coworker Michael and I just found the following solution. We placed > this in our Client’s Discovery Callback for the timebeing. As you may > notice, you can call setHost() at any time after discovery has occurred. > > > > The reason you need to perform the setHost() function, is because the C++ > SDK doesn’t automatically assume you want to use the "coaps://“ (ie. Secure > communications) version of the Resource’s URI. It assumes you want to use > the “coap://“ version and the Server will reject this if your resource(s) > were created with the OC_SECURE flag. (Note: I’ve just recently heard you > no longer need to specify the “OC_SECURE” flag as all resources are created > as Secure Resources now by default.) > > > > foo( std::shared_ptr<OC::OCResource> resource ) > > { > > // > > // Find the first secure coaps endpoint in the list of hosts. If it's > there > > // then use it; otherwise use the unsecure coap endpoint. > > // > > auto resourceHostList = resource->getAllHosts(); > > > > for (auto &host : resourceHostList) > > { > > if (std::string::npos != host.find("coaps://")) > > { > > resource->setHost(host); > > > > break; > > } > > } > > > > // If you keep a single copy of your discovered resource, take the copy of > it here for you to use later in your application. > > MyDiscoveredResources.push_back(resource); // For a quick test, just call > "resource.get()" and see if the server side is honoring your request now. > > > > } > > > > Thanks, > > > > Joey Morrow > > > > *From: *<iotivity-dev-boun...@lists.iotivity.org> on behalf of Arthur > Barros Lapprand <a...@cin.ufpe.br> > *Date: *Sunday, December 24, 2017 at 6:51 PM > *To: *Tonny Tzeng <tonny.tz...@gmail.com> > *Cc: *iotivity <iotivity-dev@lists.iotivity.org>, Rami Alshafi < > ralsh...@vtmgroup.com> > *Subject: *Re: [dev] FW: Android SECURED mode > > > > I am using both OC_NONSECURE and OC_SECURE flags when registering the > resources and attempting a GET request with the OcResource I get from the > OnResourceFound callback. Odd, isn't it? > > > > Thank you, > > A. Lapprand > > > > Em dom, 24 de dez de 2017 às 23:46, Tonny Tzeng <tonny.tz...@gmail.com> > escreveu: > > What flags did you pass to the registerResource() function? note that if > you want to communicate over non-secure endpoint, you need to pass > OC_NONSECURE flag explicitly while registering the resource. The > simpleserver server doesn't work in non-secure mode for the same reason, no > passing OC_SECURE flag doesn't imply the use of non-secured endpoint. Hope > this helps. > > > > Regards, > > Tonny > > > > On 25 December 2017 at 10:09, Arthur Barros Lapprand <a...@cin.ufpe.br> > wrote: > > Hi all, > > I got to test the ACLs Rami provided while changing the server json by > adding these ACEs: > > { > *"aceid"*: 6, > *"subject"*: {*"conntype"*: *"anon-clear"*}, > *"resources"*:[ > { *"href"*:*"*"*} > ], > *"permission"*: 14 > }, > { > *"aceid"*: 7, > *"subject"*: {*"conntype"*: *"auth-crypt"*}, > *"resources"*:[ > { *"href"*:*"*"*} > ], > *"permission"*: 14 > } > > So in theory I guess my server should respond to any request. Sadly that > didn't > work so now I'm somewhat confused. I noticed the UNAUTHORIZED_REQ message > is sent to the client by a COAP host (not COAPS). Maybe I'm compiling > IoTivity > with the wrong scons settings? Also, how do I know my client is using COAPS? > I've > seen someone asking this recently but I don't remember where. Is it also > obligatory > for me to do the pairing/onboarding/credentials stuff aside setting them > through the json? > > Thank you, > > A. Lapprand > > > > Em qui, 21 de dez de 2017 às 15:11, Rami Alshafi <ralsh...@vtmgroup.com> > escreveu: > > That’s a mistake! Thanks for pointing that out! I will fix it. The “1” at > the beginning should not be there J > > Thanks, > > -Rami > > > > *From:* Arthur Barros Lapprand [mailto:a...@cin.ufpe.br] > *Sent:* Thursday, December 21, 2017 8:02 AM > *To:* Rami Alshafi <ralsh...@vtmgroup.com> > *Subject:* Re: FW: [dev] Android SECURED mode > > > > Hi, > > I just noticed the sample you linked has "rowneruuid": > "132323232-3232-3232-3232-323232323232" in the pstat section. Is there an > explanation to that "1" at the beginning of the id? shouldn't it be the > same as the client's id? > > Thanks again, > > A. Lapprand > > > > Em qui, 21 de dez de 2017 às 10:18, Arthur Barros Lapprand < > a...@cin.ufpe.br> escreveu: > > Hi Rami, > > Sorry for the delayed answer. I'm pretty overcrumbed these days so I can't > test it right now, but the email was very useful! Like I said to the others > I'll give feedback once I manage to test those suggestions. > > Thank you, > > A. Lapprand > > > > Em ter, 19 de dez de 2017 às 15:42, Rami Alshafi <ralsh...@vtmgroup.com> > escreveu: > > Arthur, > > I meant to send this e-mail to you but I just learned it did not make to > you. Hopefully, this one will. > > Thanks, > > -Rami > > > > *From:* Wouter van der Beek (wovander) [mailto:wovan...@cisco.com] > *Sent:* Tuesday, December 19, 2017 5:22 AM > *To:* Rami Alshafi <ralsh...@vtmgroup.com> > *Subject:* RE: [dev] Android SECURED mode > > > > This is email is now on the dmtools reflector and not on the iotivity > reflector.. > > Hence Arthur can’t see this email > > > > *From:* Rami Alshafi [mailto:ralsh...@vtmgroup.com <ralsh...@vtmgroup.com>] > > *Sent:* 18 December 2017 18:43 > *To:* Wouter van der Beek (wovander) <wovan...@cisco.com>; > dmtools...@members.openconnectivity.org > *Subject:* RE: [dev] Android SECURED mode > > > > Arthur, > > Please reference my sample applications at > https://gerrit.iotivity.org/gerrit/#/c/22513/ > <https://urlf.duocircle.io/?url=https%3A%2F%2Fgerrit.iotivity.org%2Fgerrit%2F%23%2Fc%2F22513%2F&id=31d5&rcpt=ralsh...@vtmgroup.com&tss=1513689724&msgid=99c3285a-e4bf-11e7-8fcd-5f906d21262c&html=1&h=b068c5c2> > > For convenience, I will explain the server’s SVR database. > > There are 4 main sections which are ACL, Pstat, Doxm and Cred. > > Assuming your client cannot onboard devices, the server\device needs to be > in RFNOP state which is reflected in the following settings. > > The ACL must have an ACE giving the client the right permissions > > Aceid: whatever number > > Subject: set it to {“uuid”: The uuid of the client} > > Resources: information of the resource like its href and > interface and resource type. > > Permission: this is bitmask > > Set the rowneruuid of the ACL to the uuid of the client > > In the pstat section, set the dos.s to 3 and isop to true and cm to 0 and > the rowneruuid to the uuid of the client > > In the doxm section, set the owned flag to true and the devowneruuid and > rowneruuid to the uuid of the client. > > Assuming you want to use the “justworks” security model, set the cred > section like in the sample applications. > > Thanks, > > -Rami > > > > *From:*dmtools...@members.openconnectivity.org [ > mailto:dmtools...@members.openconnectivity.org > <dmtools...@members.openconnectivity.org>] *On Behalf Of *Wouter van der > Beek (wovander) > *Sent:* Monday, December 18, 2017 2:38 AM > *To:* dmtools...@members.openconnectivity.org > *Subject:* [OCF dmtools_tg] FW: [dev] Android SECURED mode > > > > FYI > > > > *From:*iotivity-dev-boun...@lists.iotivity.org [ > mailto:iotivity-dev-boun...@lists.iotivity.org > <iotivity-dev-boun...@lists.iotivity.org>] *On Behalf Of *Tonny Tzeng > *Sent:* 17 December 2017 08:16 > *To:* Max Kholmyansky <max...@gmail.com> > *Cc:* iotivity <iotivity-dev@lists.iotivity.org> > > > *Subject:* Re: [dev] Android SECURED mode > > > > Hi, > > > > We just posted an article at 01.org > <https://urlf.duocircle.io/?url=https%3A%2F%2F01.org%2Fblogs%2Fttzeng%2F2017%2Fsecurely-accessing-iot-devices-based-javascript&id=31d5&rcpt=ralsh...@vtmgroup.com&tss=1513593475&msgid=8131ebd8-e3df-11e7-8fcd-5f906d21262c&html=1&h=7e525f59> > talking > few security concept in IoTivity. Though we were using iotivity-node as an > example, I think the following steps would get your Client accesses to the > Server securely: > > (1) your Server need to register the resource with ResourceProperty.SECURE > flag in order to use the secured endpoint; > > (2) allow the "auth-crypt" connection requests in the SVD dB; > > (3) use an Onboarding Tool to establish ownership with both the Client and > the Server; > > (4) mutual install the credentials of each other by pairing the devices > with the OBT > > > > Regards, > > Tonny > > > > On 17 December 2017 at 14:38, Max Kholmyansky <max...@gmail.com> wrote: > > Hi Arthur, > > > > You should be able to communicate between the client and the server on > Android, using SECURED=1 library. > > > > First, to set your "di" (client or server) - you need to specify the "di" > value inside the DAT file (containing security information) - you can look > at the samples. I never succeeded with setting the "di" using API, and I > don't know if it's supported. > > > > Second, even using SECURED=1, in the server, you can allow any client > (even not authenticated) to access any resource. > > The relevant ACL entry looks like: (you may need to change the "aceid"): > > { > > *"aceid"*: 5, > *"subject"*: { *"conntype"*: *"anon-clear" *}, > *"resources"*: [ > { *"href"*: *"*" *} > ], > *"permission"*: 14 > } > > This is definitely not the way to configure it in production, but it should > allow you to keep developing, without caring about access permissions for a > while. > > > > Max > > > > > > > > > > On Thu, Dec 14, 2017 at 8:54 PM, Arthur Barros Lapprand <a...@cin.ufpe.br> > wrote: > > Hi all, > > I have a few beginner-leveled questions about secure mode in Android. Let > me explain the situation: > > I have created two apps (one for Server/Controlee and the other for the > Client/Controller) and I'm able to FIND and GET/POST/OBSERVE them without > problems. As this is a simple example, I now want to do the same things but > with SECURED=1. I should note that I am usually running both apps in the > same device (not the emulator, but my cellphone). > > So I started looking everywhere and discovered I could do this with a > local ACL and supposedly everything would be ok. Turns out it didn't, which > is why I am here. So my questions are: > > - Do I need anything else to use the SECURED flag in Android apart from > registering resource as secure and passing the ACL to the PlatformConfig > and configure it? > > - I read that when configuring the Platform with an ACL the DeviceID > should be set with the ID inside it. So as it failed I tried debugging the > ID, which led me to confusion about PlatformID and DeviceID. When loading > the ACL the DeviceID comes as a random byte[]. However, I can set the > DeviceID in the code and retrieve it just fine. The thing is, the ID > recieved by the Client (ServerID) isn't the same I set in the code. I'm not > sure if it's something about the encoding tricking me or if it's something > else. Can someone please shed me some light? > > > > In short, the Client can find the resources (they are registered with > SECURE type) but can't make a correct GET/POST/OBSERVE request, returning > UNAUTHORIZED_REQ. Any tips about this flag and Android are welcome. > > Sorry for the long post, thank you in advance! > > > > _______________________________________________ > iotivity-dev mailing list > iotivity-dev@lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev > <https://urlf.duocircle.io/?url=https%3A%2F%2Flists.iotivity.org%2Fmailman%2Flistinfo%2Fiotivity-dev&id=31d5&rcpt=ralsh...@vtmgroup.com&tss=1513593475&msgid=8131ebd8-e3df-11e7-8fcd-5f906d21262c&html=1&h=0ab5454f> > > > > > _______________________________________________ > iotivity-dev mailing list > iotivity-dev@lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev > <https://urlf.duocircle.io/?url=https%3A%2F%2Flists.iotivity.org%2Fmailman%2Flistinfo%2Fiotivity-dev&id=31d5&rcpt=ralsh...@vtmgroup.com&tss=1513593475&msgid=8131ebd8-e3df-11e7-8fcd-5f906d21262c&html=1&h=0ab5454f> > > > > > > > > > >
_______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
