嵌入式系统,网络化嵌入式系统的安全性讨论

网络化嵌入式系统的安全性讨论 - 系统安全 - 电脑教程网

网络化嵌入式系统的安全性讨论

日期:2007-04-25   荐:
近年来,网络化嵌入式系统的迅速发展,带动了无数的商机,从Smart-Home, Building-Automation, HVAC, 到Mobile-Computing和Ubiquitous-System, 都竞先提供网络接入口(RJ-45) ,支援远端存取功能。然而,在一个只关心Time-to-Market大前提下的开发,系统的可靠性与安全性考虑是很值得怀疑的。从嵌入式的角度想想,在一个对硬件资源斤斤计较的系统里,系统可靠性与安全性如何达到一个值得信赖的平衡点。在软件的角度上来看,一个大约1MB容量的Flash或EEPROM 如何将资源有效的和合理的分配给RTOS, Drivers和Applications。对于一个可靠的RTOS来说,Interrupts, Pipelining, Timer, Exception Handling还有其他种种的考虑因素在嵌入式的限制下,性能肯定大打折扣。市面上比较流行的RTOS就有Embedded Linux, Win-CE, XP-Embedded, QNX和VxWorks。而其中用得最广的就是Embedded Linux,其中,比较著名的有Red-Hat和UCLinux。Embedded Linux基本上是一个简化版的Linux,一般上在Compile Kernel的时候都会将所有非必要的Module unload掉,来将Image File和File System的size缩小到最低的限度。Drivers一般上是随着Kernel而存在的,而Applications就由工程师开发后,再存于 File System里。在可靠性与安全性来看,Memory的分配,Registers的安全性,数据的Addressing,Stack的处理,都过于简化。从硬件的角度来看,Processor Speed, Memory Size, Cache, Storage都是最低标准的。过于复杂的加密算法与信息处理在嵌入式系统里的实现是非常艰难的。在分析了嵌入式系统的性能后,我们来看看我们在生活中对嵌入式系统的依赖性。在Smart-Home,电灯的开关,空调系统的Thermostat,室内音频与视频系统,防盗系统,Residencial Gateway,都几乎变成我们生活的一部分了。在Building-Automation和HVAC方面,监控与触发系统,入侵检测系统, Heater, Ventilation, Air-Con, 都是与每天的营业操作息息相关的。Mobile-Computing就更为普遍了,试问谁没有用过手提电话的?3G的发展带来多媒体通讯的趋势,音频与视频就是主流了。从TDMA到CDMA,从CDMA到Wideband-CDMA,3G所提供的384kbps宽频的魅力是无可挡的。因应于Mobile- Computing的趋势,Ubiquitous-System就自然产生了。与其让每个Mobile Device成为个体产品,不如让它们也联网吧。因而,Wifi, Bluetooth, Zig-Bee, NFC的标准也随之而来。Bluetooth得天独厚得到多家厂家的支持,各种不同的profile也产生了。从最初的蓝图到如今的Audio Streaming Profile,从10米的限制到100米,1600次hopping per second,无论在频宽,速度和安全性在表面上都成立了。如今Bluetooth的研发主要是将每个Piconet达成Scattering。Wifi 提供标准的无线局域网络接口,然而WEP的安全性是很不可靠的。利用一些现有的工具如Netstumbler, Ethereal,就可以随意进行Wardriving了。而现有的Access Point本身就存在很大的安全问题,本人就曾发现通过WEB进行Firmware Upgrade的AP根本就是利用Port 69通过TFTP进行program的。通过下载和阅读Firmware的BIN File,很多敏感的信息就这样暴露了,如果用TFTP强行将修改过的BIN File download进AP里,AP就不能正常工作了。如果AP是提供Smart-Home通讯主干的话,生活作息就深受影响了。掉头回来谈谈 Bluetooth,它真是安全吗?看看Nokia Smart-Phone和O2-XDA的流行程度,真令人捏一把冷汗。进行Bluesnarfing, Bluejacking的难度一天比一天简单,工具一天比一天傻瓜,再加上用Smart-Phone和XDA的人士根本对Bluetooth的安全性一窍不通,很多根本上就不知道自己一直打开着门,让不知名人士看着它所发出的讯息和记录着它的MAC Address。很多anonymous的message就是这样产生的,不许要很高深的技巧。通过利用一些软件,对phone-book和 message的下载也是轻而易具的。也许,Cabir.A和Cabir.B的教训给我们带来了正面的影响,它让我们真正去注意Bluetooth在 Mobile Device里的安全性。一个简单的Symbian installation file (.sis) 通过对本机phone-book的记录,就可以随意地传播了,可悲啊。如果有一天对Symbian的系统逐渐精通,Bluetooth的exploits 绝对不是什么问题。

[1] [2]  


再谈回网络化嵌入式系统,一般是选用controller配合Ethernet Controller进行操作的。Controller多是选用intel的8051和Motorola的68000;Ethernet Controller则是用Realtek的RTL8129/8139, ASIX, 或是SMSC的产品。对于较高档的则用Processor配合Ethernet Controller。一般所用到的processor都是RISC,例如SC12,SCENIX,ZILOG,IP2022。本人试过用port scan或ping -l 65000 <target> -t 就轻易将SC12给完全击溃了,联络开发商就声称暂时没有解决方案,当时这颗IC所开发的产品的确很具新意,公司就这样批准卖出去了,到现在好多系统还在操作,汗颜。进来改用IP2022, 很喜欢它160MHz的速度,配合VLIW,虽然是跑在1MB的RAM上,感觉上很不错。然而,花在修改RTOS以解决ping flood的时间与精神,一句话,苦啊。TCP Stack本身就是相当复杂的,在嵌入式系统里完整实现是谈何容易。然而,故事还没有结束,这只是Hardcore Processor处理方式。应于FPGA与CPLD的发展,Softcore Processor的时代逐渐开始了。Softcore Processor是用VHDL或者VERILOG硬件描述语言写成,经过Synthesis Process成Netlist,再Place and Route (P&R) 成image file,最后program进FPGA或CPLD里的一种处理方式。Softcore Processor与Embedded Linux或许是绝配,在Portable和Flexsible的论点上是,然而在Reliability, Stability上就不敢恭维了。本人曾用XILINX的Picoblaze烧进Coolrunner-2 CPLD和用Microblaze烧进Spartan-3 FPGA,一般上用是没问题,想进一步的话就得好好考虑清楚了。也曾使过用ALTERA的SOPC Builder设计一个NIOS Processor再通过Quartus进行Synthesis然后烧进Stratix FPGA里,配合Microtronix的uCLinux的确感觉不错,还可以玩玩OTA进行radio firmware downloading,然而,玩玩可以,真正开发产品得三思,不然出事的话,饭碗可保不住了。

看着网络化嵌入式系统的发展,无可否认,Softcore Processor将来肯定会有所出息,本人在空余时间也有想着如何将mysql简化后再移植进uCLinux里,让它操作在FPGA上,然而,出于对各种因素的考虑,真的不知到何时才能将一套网络化嵌入式数据库开发出来。默默地在耕耘与努力中。



(出处:http://www.sheup.com)


 [1] [2] 

标签: