Paho Tls 双向认证

Eclipse的Paho开源项目,默认TLS只支持对MQTT服务器的单向认证,官方Service中己集成相关方法:

MqttConnectOptions conOpt;

MqttAndroidClient client;

uri = “ssl://”;

InputStream ins = this.getResources().openRawResource(R.raw.ca);//ca.bks是由ca.crt通过Keytool工具导出的

String keypassword = “123456”;

conOpt.setSocketFactory(client.getSSLSocketFactory(ins, keypassword));

实现双向认证需要自己生成SocketFactory,具体代码如下:

MqttConnectOptions conOpt;

MqttAndroidClient client;

uri = “ssl://”;

InputStream ins = this.getResources().openRawResource(R.raw.ca);//ca.bks是由ca.crt通过Keytool工具导出的

InputStream clientIns = this.getResources().openRawResource(R.raw.client); //client.p12是由clinet.crt与client.key用openssl 导出的

String keypassword = “123456”;

conOpt.setSocketFactory(get2SSLSocketFactory(clientIns,ins,keypassword,keypassword));

… …

public SSLSocketFactory get2SSLSocketFactory(InputStream clientKeyStore,

           InputStream ServerKeyStore, String clientPassword, String ServerPassword)

           throws MqttSecurityException {

       try {

           SSLContext ctx = null;

           SSLSocketFactory sslSockFactory = null;

           // for server key store

           KeyStore ts;

           ts = KeyStore.getInstance(“BKS”);

           ts.load(ServerKeyStore, ServerPassword.toCharArray());

           TrustManagerFactory tmf = TrustManagerFactory.getInstance(“X509”);

           tmf.init(ts);

           // for client key store

           KeyStore kts = KeyStore.getInstance(“PKCS12”);

           kts.load(clientKeyStore, clientPassword.toCharArray());

           KeyManagerFactory keyManager = KeyManagerFactory.getInstance(“X509”);

           keyManager.init(kts, clientPassword.toCharArray());

           // init

           ctx = SSLContext.getInstance(“tlsv1”);

           ctx.init(keyManager.getKeyManagers(), tmf.getTrustManagers(), null);

           sslSockFactory = ctx.getSocketFactory();

           return sslSockFactory;

}…

   }

其中关键在PKCS12格式证书的生成,需要使用client的crt与key

openssl pkcs12 -export -clcerts -in client.crt -inkey client.key -out client.p12

之前走了很多弯路,在这个地方使用与生成ca.bks的方法来生成client证书,总是报错:

javax.net.ssl.SSLHandshakeException: javax.net.ssl.SSLProtocolException: SSL handshake terminated: ssl=0x75c72988: Failure in SSL library, usually a protocol error

error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure (external/openssl/ssl/s3_pkt.c:1256 0x7851af18:0x00000003)

SSL/TLS的加密码比较复杂,各种证书格式,加上需要跨平台通讯,问题比较多,在与Mosquito服务器通讯时,发现Tls的版本不对也会报错,

MqttException (0) – javax.net.ssl.SSLHandshakeException: javax.net.ssl.SSLProtocolException: SSL handshake aborted: ssl=0x7861ada8: Failure in SSL library, usually a protocol error

error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version (external/openssl/ssl/s23_clnt.c:741 0x71e78cf8:0x00000000)

Paho项目貌似只支持到Tlsv1,而服务器用的是Tlsv1.2,导致握手失败。

Paho使用ANT编译出错与Maven

Paho的官方库中克隆下来的mqtt client导入Eclipse竟然编译不过,给Paho Project提了一个BugBug 440052 – Paho mqttv3 client can’t be build sucessfully by defaul.

这么明显的错误,项目人员不可能不知道吧,并且他们有Daily Build,在官网都有每日编译后的版本发布。

怀疑是不是自己的编译环境有问题,仔细看了看,工程中发现Pom.xml,之前一直没接触过Maven,看了些资料发现,整个Paho项目应该是用Maven构建的,所以自己在导入Eclipse后使用ANT编译出了问题(但这的解是个问题,看官方的答复)

Maven的介绍参考这篇文章:Maven 2.0:编译、测试、部署、运行

总结下我所了解的项目编译构建工具:

1  

Make

MakeFile

C/C++

2

ANT

Build.xml

Java

3

Maven

Pom.xml

Java

4

ADT

AndroidManifest.xml

Android

5

VSTS

*.sln
*.suo

C#,VB

6

gradle

build.gradle

Java

以上可以看出来,这些工具的本质是一样的,编译规则,文件关连及项目相关信息的存储,使用工具进行编译,只是各有各的优点且都在不断进化。

Android端直接使用MQTT协议与第三方PUSH服务对比

AndroidMQTT使用基于EclipsePaho项目库,Broker使用网上免费的Mosquito服务器。第三方使用Baidu云推送。从以下四个方面对比:

一,到达率对比
         在相同的网络环境(WIFI/GPRS),两者基本都能够及时收到,延迟在1S之内,测试中偶现有延时送达的,暂没有发现丢包或收不到的情况.

          二者在被进程管理软件杀死后,默认都无法自动重启,不能继续与服务器进行沟通。要做到死后重生,需要采用特殊处理,如提高Service的优先级,设置Service在内存中的驻留方式,在ServiceStop函数当中重新启动等方法。

二,所消耗的流量对比

        Android端设置心跳间隔为5分钟,测试一个小时,推送6次信息,每次平均20Bytes,检测软件上看共消耗2.3KB,按这个流量算,一个月约需要消耗1.6M的流量。

        Baidu云推送,官方给的数据是,空载流量0.8-1.2M/月。

三,功耗对比

       测试环境:使用同一台手机,仅开启Wifi(排除电话,短信等通知信息对电流的影响),设置心跳间隔为5分钟,测试其间平均发送6次推送,结果如下:

E760(Android4.0)

底电流(平均值)

10分钟平均电流(测试3轮求平均)

30分钟平均电流(测试3轮求平均)

仅开Wifi待机

4.2mA

7.2mA

6.7mA

仅开启MQTT

4.2mA

7.7mA

7.6mA

仅开启百度云推送

4.2mA

7.8mA

7.3mA

    从对比结果看,开启MQTT或云推送,对平均电流的影响不大,平均每日耗电约12~14mAh. 网上资源显示实测移动设备空载耗电每日15-50mAh。WifiGPRS3G不同网络环境可能会稍有差距。

综上:使用MQTT与第三方Push在流量及功耗上没有太多差距,测试过程中MQTT能与服务器建立稳定的长链接,并且从查找的资源看AndroidAPP基本上都是用MQTT直接做Push服务的,没有例子同时与第三方Push联合使用的,因此如果能够自建MQTT服务器的话,完成可以自己实现Push服务。

欧瑞博智能家居套件试用报告

     周未试用了两天欧瑞博智能家居套件,包括一个WiFi智能插座,一个WiFI智能遥控器:

优点:1.入网还算便捷,长按插座或遥控器上的开关,红灯闪烁进入配置模式。

         2.多设备免重复添加,即只需一台手机配置,同一网络下的其它手机直接搜索即可。

         3.设备断电,移动位置仍可以继续使用,不用重复配置。

         4.设备反映及时,按下基本同时完成设备操作。

         5.免用户注册与登陆即可实现远程控制

 

缺点:1.APP上的功能太少,只有设备列表与模式控制,并且UI美观不够,还可以做的更人性化。

         2.IOS上的APP问题很多,经常丢失链接。

         3.UI给用户的感觉比较迟钝,像按下按钮调整电视音量,我要连续减少音量,但每按一次,UI上会有个小圈在转,不连续感觉。

         4.智能插座的动静太大,每次开关都有“啪啪”声,很不安全的感觉。

         5.远程控制功能没有介绍,都不知道有此功能。免登陆很方便,但有安全隐患。

背后的原理:

      优缺点大家讨论了很多,这里深入分析下这些设备的实现原理,以插座为例:

1.闪联功能:即配置入门功能的实现,长按插座开关,进入红光快闪状态,此时插座上的Wifi应该是处理搜索模式,搜索一固定的WIFI AP热点,此热点就是客户端APP进入配置模式后打开的,当插座找到此AP后,会获取把要链接的WIFI名称及密码(在配置的时候用户在APP上输入的),之后配置完成,插座就能链接到家里的Wifi路由上了。之后就是普通的Wifi通信。

2.免登陆远程控制功能:每个设备如这个插座都有一个唯一的UUID,配置成功后,此设备便与欧瑞博的服务器通过Wifi建立长链接,这样,当用户离开家后,如通过3G再控制此插座,就会在服务器上查找对应的UUID,找到后,把控制命令下发到插座。这样的确很方便使用,但安全隐患很大,理论上知道了此UUID,就任何人可以随便控制了,也没有用户名密码的保护。

我们最近也在做一款智能控制套件,功能要“高大上”些,以下几个方面觉得可以吸取下:

        1.入网配置,做到比较快捷方便,不要为难用户。我们上一个U+项目,采用的是扫描二维码配置入网,先扫描后仍需要按键入网,流程上不如欧瑞博的简单。

        2.反应速度,我们要通过云实现远程控制,设备能不能及时反应有待考验。

普及型智能家庭的需求分析及实现方案

1.用户需求:

从自己的生活出发,总结了下哪些方面可以改进或者更方便自己的生活.

时间: 活动: 关心点: 原来: 改进:
11:00–6:00 睡觉 家里的安全 锁好门窗 家庭安全系统,(门窗)侵入报警,关联110
起床上卫生间,亮灯 手动开关灯 下床压力感应,脚灯逐渐亮起,朝那个方向走就只亮哪个方向的灯
6:00–7:00 起床 早饭 起来做 前一天晚上都己预约好,电饭煲,微波炉,煮蛋器等.
天气,新闻 看手机,报纸 在刷牙,洗脸凡有镜子的地方,都会有天气即早间头版定制的新闻显示
7:00–7:30 上班路上 路况 听交通广播 打开导航,显示实时路况,提前规划路线
新闻 听广播 车内计算机(手机)自己播放己订阅的分类新闻
7:00–5:00 上班 孩子的安全 打电话? 小孩的手表即带的GPS,打开手机/网页,即可查看孩子的实时位置,心跳等生命体征是否正常.
5:00–5:30 回家 进门 钥匙,家里的电器 无钥匙进入(密码,指纹),家庭OS的自动问候,自动打开电视,灯光,热水.
8:00–9:00 上网 购物 只能看图片,描述 3D试衣,试戴,
9:00–1:00 游戏 好玩 手柄 Kinnect的体感游戏,同时锻炼手体,与家人/朋友一起互动游戏.

不够全面,这里只是引子,可以发散,只是平常的一日,还有周未休息日,节假日都会有很多可改进的地方,不同的年龄,职业,性别的人都不一样。

综上,家庭的智能化还有很大的发展空间,有很多具体的方面可以切入,大众的接受度会随着生活水平的提高慢慢提升。

针对富裕家庭,有如Haier U-Home之类的高端一体化解决方案,本文主要讨论针对大多数普通家庭(如90平)实施智能化的方案。着重是在大众可接受的成本范围内实现更多功能。

2.新房装修的实现方案:

智能家庭至今没有统一的协议规范,目前常用的包括433,zigbee, wifi以及ble.他们之间的优劣有很多的资料可以参考,对于新房而言,最重要的选择一种统一协议,多于一种无论是对于控制还是互通互联,都造成不小的麻烦,成本也会高出不少。这里以zigbee为例:

a.) 家里的所有插座及灯的控制开关,都使用带有zigbee模块的产品。

b.) 家里的窗帘,窗户跟据自己的需要也都换用带zigbee控制模块的产品。

c.) 新买的家用电器,包括电视,空调,热水器,先衣机之类尽量选购带Wifi模块的。(似乎支持zigbee的产品较少)

还有一种变通的解决方案,常规的红外家电,使用zigbee转红外模块实现控制。

d.) 最重要的是有一个控制中心,实现最简单的星型网络。这是我们目前正在做的。但相似功能的产品己有不少,可以淘宝zigbee.

 ehome

如上图,控制中心起到了关键做用,但实际也并不复杂,不一定非要买一个全功能高端产品,用自己的智能手机外接一个zigbee的模块即可,这也是我们在研究的方向。

如果等不及我们的方案,自行淘宝zigbee。

3.在现有住房基础上的改造方案:

基本过程同上,主要是开关的改造。比新装修稍微麻烦些。

4.展望

理想的情况是使用Ble作控制协议,之后大部分手机都会支持ble。控制中心,其实也就是一个手机。这会是最优化的解决方案。