0

How to set the own password for the Daemon connection between AJTC and AJSC

asked 2014-08-07 03:26:27 -0800

congtam gravatar image

updated 2014-08-08 09:23:30 -0800

bspencer gravatar image

Hi everyone, I'm working on the Alljoyn project. My job is to develop the applications on microchip with AJTC. In the connection request from AJTC to AJSC, for the security reason, I want to set my own password for them. I have no idea how to do. Has anybody got an idea about this problem?

Updated with more questions after looking at the source code:

I saw again the source codes of the example: service, chat, client. I considered that we don't need to set PassworkCallback for a peer (or busAttachment) into Daemon. But we need in the case that AJTC borrows Daemon. As what I can understand, this password are used for the challenge between AJTC and AJSC Daemon. These numbers of password are used to create the credential, aren't they? Thanks a lot and sorry for the basic question :)

Thanks in advance,

edit retag flag offensive close merge delete

Comments

Hi bspencer, I understood more features of Alljoyn,thanks a lot for the kind reply.

congtam ( 2014-08-08 01:06:22 -0800 )edit

@congtam I have converted my response to an answer, please let me know if you would like more information and mark as solved if you feel inclined to do so. Thanks.

bspencer ( 2014-08-08 06:49:03 -0800 )edit

1 answer

Sort by ยป oldest newest most voted
0

answered 2014-08-07 13:21:33 -0800

bspencer gravatar image

updated 2014-08-08 09:41:05 -0800

The nature of AllJoyn is that everything is discoverable and the AllJoyn Security APIs for marking an AllJoyn Interface as being secure is what is protected. There is in the 14.02 a pin code that is used to authenticate against an AllJoyn Router as a means to allow a trusted connection to occur. This is not security in the normal sense and is really just a way to filter which AllJoyn Thin Library devices can connect to a given AllJoyn Router.

The new questions you have I'm confused what you mean by "borrows daemon". The AllJoyn Router (daemon is legacy term) really just moves messages through the network to the correct endpoints at it's simplistic definition (it does more than just this). When an AllJoyn Thin Client Library application or ANY AllJoyn application on a device connects to an AllJoyn router they offload the work to the router for it to move messages to the correct endpoints. They do not take control of the Router in any way.

The Authentication of a Thin Client Library app to an AllJoyn router is mutually exclusive from AllJoyn Security. When AllJoyn Security is enabled it takes place on the BusObject & AllJoyn Interface communication. It is triggered on demand and starts up a SASL exchange in the Security 1.0 that we have today. Currently there are 3 security mechanism that can be used (only PIN/Passphrase for Thin Client): PIN/Passphrase, username/password, certificate. Once two applications are authenticated against each other the data will be encrypted and ONLY the application endpoints have the ability to decrypt the messages, the AllJoyn Router's role is to move the message to the endpoint, it cannot decrypt the data. An AllJoyn application has the ability to have a mix of secure and insecure AllJoyn Interfaces & Bus Objects. This allow for public/private APIs, or Guest and Owner APIs. The core security architecture is changing from what I hear in conversations inside the AllSeen Alliance. You can see that there is a placeholder on the wiki.allseenalliance.org page for security enhancements.

Net net, AJ Thin communication with an AJ Router should be open to allow ANY Thin Library device in a network the ability to interact with other AllJoyn applications/devices. When people talk about security and trying to limit which device an AJ Thin application can connect to it breaks down the openness and interoperability that AllJoyn is solving. We need to move away from thinking of my sensor device that I build will connect just to my other device and will be a closed ecosystem. It very well could be that the sensor device I create ends up being used by some other developer to create something that myself and the world never thought possible. This happens because the sensor device speaks AllJoyn and, as such, exposes itself as APIs (AllJoyn Interfaces) across the network to be discovered, connected to, and interacted with by any other application. So when you ... (more)

edit flag offensive delete publish link more

Comments

Hi, Bspencer, thanks a lot for your information. It's very interesting and useful. I have some confusions. Could you help me to understand more? The code PIN what you mentioned in the first paragraph above is the password "1234" being set in the PasswordCallback, isn't it? When I changed it in both the AJTC and AJSC, it didn't work.Thanks

congtam ( 2014-08-23 10:27:37 -0800 )edit

@congtam, the PIN code is not the same as what is being set in PasswordCallback, this callback is for interface level security. See: https://git.allseenalliance.org/cgit/core/ajtcl.git/tree/samples/secure/SecureService.c With the 14.06 software there is no longer an authentication between a AJTCL and an AllJoyn Router. The method SetBusAuthPwdCallback has been deprecated. The model you want to follow to lock down your MCU software is to use a secure interface.

bspencer ( 2014-09-26 12:42:17 -0800 )edit
Login/Signup to Answer

Question Tools

Follow
1 follower

Stats

Asked: 2014-08-07 03:26:27 -0800

Seen: 147 times

Last updated: Aug 08 '14