1概述
该文档描述了SyncMLDM的保证其需求的方法和技术。
SyncML组织是一个非盈利组织机构，他们定义了开放式的数据同步和设备管理协议。对于SyncML，数据同步和设备管理基于一组不同的、私有协议，每一个的功能仅定义了非常有限的设备、系统和数据类型。这些非互用的技术由用户、厂家、服务器提供者和开发人员，协议的任务复杂组合在一起。而且，不同的、私有的数据同步和设备管理协议的增支使得移动设备的扩展使用受到阻碍，使得数据访问和传输受到限制，用户灵活性也受到限制。
SyncML组件
SyncML规范包括以下几个主要部分：
基于XML的描述协议（AnXML-basedrepresentationprotocol）
同步协议和设备管理协议（Asynchronizationprotocolandadevicemanagementprotocol）
协议的传输绑定（Transportbindingsfortheprotocol）
设备管理框架描述（Adevicedescriptionframeworkfordevicemanagement）
4介绍
SyncMLDM是一个基于SyncML的协议。它的目的是允许对于支持SyncMLDM协议的任何设备进行远程管理。由于在现在和未来设备上需要管理的数据非常的庞大，保证这些数据的安全是必要的，在很多情况下，设备上的数据管理操作是很频繁的。在一些情况下，一些机密数据或者给数据的机密性一定的保护措施应该被考虑。在其它情况下，数据的完整性也应该被维护。所以最终实体（设备和设备管理服务器）之间的相互鉴权就显得很重要。
5SyncML设备管理安全
5.1证书
下面列出了四个在设备和设备管理服务器之间交换的证书，这是其它鉴权方式的基础：
服务器ID（指定设备管理服务器的唯一ID）
用户名，向设备管理服务器指定设备
密码，与用户名或服务器ID一起使用
nonce（随机数），用来在使用静态数据的Hash（散列）算法的地方对重复攻击进行阻止
解释：nonce是一个唯一的不重复整数，通常可用随机数来模拟。
服务器为了对设备进行鉴权，用户名、密码和nonce都是要求的。
服务器必须（MUST）对其服务的每个客户端使用不同的密码，这样在服务器同一个客
户端打交道的时候就不会受到另一个客户端（具有该密码的共享机制）的影响。
5.2证书的初始化准备（provision）
服务器的证书需要初始化就提供，这样设备才能鉴权指定的服务器。
基本上，任何适当的技术将至少传送最少用于建立DM会话的信息，当然，包括服务器ID、密码和nonce，外加服务器地址。
5.3鉴权
SyncMLDM使用相同的常规技术进行鉴权[SYNPRO]。即是说或者客户端或者服务器有可能（MAY）发送证书给对方或要求对方发送证书。
OMADM协议客户端和服务器必须互相鉴权。可以在不同的层来做鉴权。OMADM服务器必须在传输层支持客户端服务器鉴权。在建立会话期间，当传输层安全被OMADM客户端请求的时候，服务器必须在传输层请求客户端鉴权。有些客户端可能不支持传输层鉴权，服务器必须在应用层对这样的客户端鉴权。如果传输层没有一个足够强壮的鉴权特性，就必须使用OMADM协议层鉴权。
不管是客户端还是服务器都可以互相发送证书或提出让对方发送。
不支持在传输层客户端鉴权的OMADM客户端必须支持OMADMsyncml:auth-md5类型鉴权。支持在传输层相互鉴权的OMADM客户端也可以（MAY）支持如OMADMsyncml:auth-md5类型鉴权的OMADM鉴权机制。当传输层相互鉴权已经完成但是客户端没有反馈请求鉴权类型，会话必须终止时，DM服务器仍然可能（MAY）产生一个MD5的问题。用于传输层鉴权的证书的provision不在OMADM安全范围之内。
5.3.1MD-5鉴权
MD-5鉴权通过在SyncHdr的Cred元素中应用简单的“用户名：密码”(userid:password)来完成，如下所示：
1.1
DM/1.1
1
1
http://www.syncml.org/mgmt-server
IMEI:493005100592800
Bruce1
syncml:auth-md5
18EA3F厖S
………………………MD5鉴权
5000
5.3.2MD-5摘要计算
应用在Cred元素中的摘要是这样计算出来的：
LetH=theMD5Hashingfunction.MD5Hash函数
LetDigest=theoutputoftheMD5Hashingfunction.MD5Hash函数的输出
LetB64=thebase64encodingfunction.base64编码函数
Digest=H(B64(H(username:password)):nonce)上面函数组合计算得到摘要
该计算允许鉴权者再不知道密码的情况下进行验证。密码既不能所谓Cred元素的一部分发送，也不是必须要求鉴权者明确知道的，因为鉴权者仅仅需要存储一个之前已经计算除的“用户名：密码”字符串的Hash量。
5.3.3密码和nonce的用法
密码和nonce都推荐至少128bits（16随机的8位字节）的长度。
nonce的值必须（MUST）在一个来自于设备或者设备管理服务器的challenge（质询）中发布。在被发送的证书先于一个正在发行的challenge的情况下（即没有得到新的nonce，但证书已经得到了），最后使用的nonce将被重新使用。鉴权者必须意识到证书的发行者可能正在使用一个陈旧的nonce（即是说该nonce由于一些先前的通信失败或数据丢失的问题已经无效）。正因为如此，如果鉴权失败了，必须连同提供新的nonce一起制造更多的challenge。
一个新的nonce应该（SHOULD）用在每个新会话中。nonce值的顺序（通过会话看）应该是难以预测的。
5.3.4未经鉴权代理的质询（challenge）
在一些场景中，客户端和服务器可能需要接受代理的challenge，该代理还没有被成功鉴权。例如，考虑这种情况，客户端和服务器都有已经过时的nonce，且使用了MD5或HMAC鉴权法。如果他们都丢弃Chal元素，则它们将没有机会更新它们的nonce，也永远不能互相鉴权。为了避免这种情形，即使nonce是从一个未经鉴权的代理那里接收到的，也建议客户端和服务器使用最新接收到的nonce来建立Cred元素的内容。并建议客户端和服务器不应对存储的从未经鉴权的代理处接收到的下－个nonce的拷贝进行写覆盖(over-write)，因为那将会允许恶意的代理用有害的nonce去替换有效的nonce。
附：对Chal元素的解释
描述：当使用syncml:auth-md5或syncml:auth-MAC时，NextNonce的Meta元素的格式必须指定且其必须为b64
举例：
5.4完整性
SyncMLDM消息的完整性是使用HMAC-MD5[RFC2104]来完成的。
一个Hash消息鉴权代码必须用在每个在设备和设备管理服务器之间传送的消息中（如果任一个实体要求这样做）。这种完整性检验的使用是可选的。
5.4.1怎样请求完整性检验
完整性检验以相同的方式请求，同时进行鉴权质询。对syncml:auth-MAC的质询（challenge）将使用其Type、Format和NextNonce与syncml:auth-md5相同的Meta数据。一个新的鉴权类型：syncml:auth-MAC可能被客户端或管理服务器请求（或仅仅在一个曾经发行的challenge前提供）。当使用的时候，鉴权类型必须在传输头中指定且决不能用Cred元素指定。
注意一个challenge的接受者必须对请求的鉴权类型进行响应，另外会话必须被终止。举例，一个challenge请求HMAC产生一个有效的基本鉴权证书应答，不管实际提供的鉴权证书的有效性如何，会话都将被终止。
5.4.2HMAC是如何计算的
HMAC的计算如下描述，且使用MD-5作为它的Hash函数。HMAC依赖于一个共享秘密（或密钥），该密钥在这个应用中本身就是一个Hash量。
HMAC值应该通过base64编码进行计算，摘要结果应用的结果如下：
H(B64(H(username:password)):nonce:B64(H(messagebody)))
这里H(X)是所选摘要算法（MD-5）应用到8位字节数据流X上的结果；B64(Y)是八位字节数据流Y的base64编码。
5.4.3HMAC如何在SyncMLDM消息中指定
HMAC本身也必须和原始的SyncMLDM消息传输。该方式通过插入HMAC到一个叫做x-syncml-hmac的传输头来完成。这项技术同样地应用在HTTP，WAP和OBEX上。HMAC最初由使用整个消息体的发送者计算，或者以二进制形式（WBXML）或者以文本形式（XML）。接收者对到来的消息使用相同的技术。
头x-syncml-hmac包括多重参数，包括HMAC本身，用户或者服务器标识，和一个可选的对使用哪种HMAC算法的指示。（目前定义的只有MD-5）
x-syncml-hmac的值定义为用逗号分开的属性值对。规则”#rule”和术语”token”、”quoted-string”根据它们在HTTP1.1规范[RFC2616]中的定义来使用。
这里是正式的定义：
syncml-hmac=#syncml-hmac-param
这里：syncml-hmac-param=(algorithm|username|mac)
下面的参数进行了定义：
algorithm="algorithm""="("MD5"|token)
username="username""="username-value
mac="mac""="mac-value
这里：
username-value=quoted-string
mac-value=base64-string
参数算法可以省略，这时MD5是假定的。参数username和mac必须被指定。
注意一个base64-string是base64字母表中的字符的任意串联，在[RFC1521]中定义。
举例：
x-syncml-hmac:algorithm=MD5,username="RobertJordan",
mac=NTI2OTJhMDAwNjYxODkwYmQ3NWUxN2RhN2ZmYmJlMzk
username-value是来自于SyncHdr中的Source元素的LocName同样的字符串，且代表了消息发送者的标识。（注：LocName是用来发送用于MD5鉴权的userid的）消息头中username的存在允许HMAC的计算和确认是与消息自身的解析相独立的。
接收消息的步骤是：
1、检查消息头中的HMAC；取出它和用户名；
2、使用用户名从存储中查找密钥。该密钥本身是一个Hash量，由用户名和密码组成，如前面描述的；
3、或者解析该消息；
4、或者使摘要有效。
在或者次序的步骤中，摘要基于完整的消息体进行计算，或者是一个二进制XML文件
（WBXML）或一个文本XML文件。
在接收者计算出HMAC后（如果存在），提供的HMAC和计算出的HMAC可以比较以便确定发送者的可靠性和消息的完整性。如果期望使用HMAC（例，如果它的一个challenge已经发布）且它或者userid没有在正确的传输头中提供，则就导致一个鉴权失败的结果（就好像它们已经被提供且是不正确的）。
一旦使用了HMAC技术，它必须用于所有后来的消息直到SyncMLDM会话结束。回发给SyncHdr的状态代码必须为200来表明对消息的鉴权。另外，NextNonce必须被发送并用于下一次HMAC证书检查。达不到这些需求必须引起会话的一次终止。
5.4.4HMAC和nonce值
依赖于MsgID(消息标识)的nonce的作用就像带有一个值的计数器，它随着每个新消息而增加。因为HMAC算法要使用nonce和MsgID（与消息联系在一起），所以改变每个新消息的nonce的效果就达到了。
5.4.5提供鉴权和完整性的传输协议的使用
注意HMAC特征的静态一致性需求和它的使用是独立的。客户端和服务器都不能提供HMAC，除非要对其质询。例如，如果认为一个已经鉴权的传输协议连接已经建立了，然后设备或设备管理服务器可能选择不鉴权。在这种特殊情形下，服务器和客户端都不期望发行challenge。
5.5机密性
在SyncMLDM协议中机密性有两个主要方面：在传输协议之上传输的信息的机密性和设备管理服务器之间信息的机密性。
5.5.1传输过程中的信息机密性
当前在OMADM协议本身里面没有内嵌的能力来提供设备和设备服务器之间数据传输的机密性。无论怎样，已经有很多技术能够和SyncMLDM协议兼容的来提供这个能力。
5.5.1.1支持加密的传输层协议
推荐支持加密的传输层协议的应用，鼓励使用如TLS或HTTPS的传输协议。注意可能使用这些传输，可提供机密性，也是没有鉴权的。这些情况下，机密性可能处于危险中。
5.5.1.2管理对象加密
SyncMLDM完全支持加密的管理对象的使用，对象可能在设备管理树中保持加密性，或者设备或设备管理服务器在接收基础上对其加密。
一个对象可能在通过一个非加密传输层传输之前被加密，且在设备管理服务或设备的存储空间中保持加密态，或者可能在接收后立即对其加密并以非加密的格式内部存储。这取决于执行方式。
使用的加密技术没有限制，因为它对SyncMLDM协议本身是独立的。
5.5.2设备管理服务器之间的信息机密性
在来自于另一个DM服务器的DM控制下，SyncMLDM提供了能够使一个管理服务器
把任何存储的数据变成私有的能力。通过应用ACL使这个变得更加容易，ACL允许任何团体或任何私人的设备管理对象的保护。
5.5.2.1ACL
ACL允许基于设备管理服务器ID作一个层次上的访问权限分配。对ACL的详细描述可在[DMTND]中找到。
5.6初始会话通知
SyncMLDM提供了让一个管理服务器发请求给一个设备来建立管理会话的能力。这个消息的安全依赖于一个摘要。这个消息的规范能够在[DMNOTI]中找到。
5.7Bootstrap
Bootstrap过程是一个敏感的过程，在通信双方之前没有建立任何联系或相互不知晓的情况下，也可以建立通信。在这种情况下HMAC(M=HMAC-SHA(K,A))计算的输出编码成一串16进制数字的字符串，其中，每两个连续数字代表一个字节。其后，则将HMAC计算十六进制编码后的输出则包含入Bootstrap的安全信息。
在Content-Type中，传递安全方法和HMAC值时，采用如下格式：
Content-Type:MIMEtype;SEC=type;MAC=digest
其中，\
MIME类型为application/vnd.syncml.dm+wbxml(bootstrap不能使用XML格式)
SEC的取值为“NETWORKID”,“USERPIN”,或“USERPIN_NETWORKID”，也可以使用其他的安全类型。
Digest为上面所述的HMAC值。
5.7.2.2传输方式
由于Bootstrap消息可以通过任意方式传输至DM客户端，因此，在对一个设备进行安全Bootstrap时，必须引入合适的安全机制。如果传输方式本身提供合适的安全机制，则必须使用其自身的安全方法。否则，使用传输方式无关的安全机制。
特定传输方式的安全机制归档至传输绑定文档（[SYNCHTTP],[SYNCOBEX],[SYNCWSP].）。
5.7.2.3与传输方式无关的安全机制
以下小节说明传输方式无关的安全方法。客户端和服务器必须支持但不仅限于NETWORKID和USERPIN两种方法，只要引入合适的bootstrap安全机制，也可以使用其他方法。在实现bootstrap业务时，可以考虑联合使用密钥（随机，难以获取等)、传输方式以及使用环境作为安全机制。
5.7.2.3.1NETWORKID
该方法依赖于设备和网络提供商在bootstrap之前就已知的某类共享密钥，比如IMSI(GSM制式下)或ESN（CDMA制式下）。实际使用的共享密钥取决于网络提供商和具体设备。该方法的优势在于，无需用户参与。
NETWORKID方法要求如下：
发送Bootstrap消息时，同时发送采用该共享密钥和Bootstrap消息所计算出的HMAC值，参见5.7.2.1章节。
传输Bootstrap消息所用的协议，必须能同时传输OMADMBootstrap包和HMAC值。
安全类型应该指定为“NETWORKID”。
支持OMADM的设备和服务器必须支持NETWORKID方法。
5.7.2.3.2USERPIN
该方法于一个PIN（个人身份号码）码，该PIN码必须通过带外的方式告知用户，或在Bootstrap开始之前确认。
USERPIN方法要求如下：
发送Bootstrap消息时，同时发送采用该共享密钥和Bootstrap消息所计算出的HMAC值，参见5.7.2.1章节。
传输Bootstrap消息所用的协议，必须能同时传输OMADMBootstrap包和HMAC值。
安全类型应该指定为“USERPIN”。
支持OMADM的设备和服务器必须支持USERPIN方法。
5.7.2.3.3USERPIN_NETWORKID
这是NETWPIN方法和USERPIN方法的组合。它要求使用网络供应商和设备之间的共享密钥和用户PIN码。
USERPIN_NETWORKID方法要求：
发送Bootstrap消息时，同时发送HMAC值。该HMAC值，组合使用PIN码和网络供应商与设备之间的共享密钥(PIN:secret)进行计算，计算方法参见5.7.2.1章节。
传输Bootstrap消息所用的协议，必须能同时传输OMADMBootstrap包和HMAC值。
安全类型应该指定为“USERPIN_NETWORKID”。
支持OMADM的设备和服务器可以支持USERPIN_NETWORKID方法。
5.7.2.3.4智能卡方式Bootstrap的安全性
本质上，智能卡方式Bootstrap是一种非传输方法，其Bootstrap信息是安全的。
智能卡是对[GSM11.11]、[TS151.011]、[TS102.221]、[TS131.102.11]、[C.S0023-B_v1.0]规范所述卡的统称。
Bootstrap数据可以存储于智能卡中。DM客户端对Bootstrap数据的处理在[DMBOOT]规范中进行定义。
附：Base64编码的解释
Base64是网络上最常见的用于传输8Bit字节代码的编码方式之一，在发送电子邮件时，服务器认证的用户名和密码需要用Base64编码，附件也需要用Base64编码。按照RFC2045的定义，Base64被定义为：Base64内容传输编码是设计用来把任意序列的8位字节描述为一种不易被人直接识别的形式。（TheBase64Content-Transfer-Encodingisdesignedtorepresentarbitrarysequencesofoctetsinaformthatneednotbehumanlyreadable.）。Base64要求把每三个8Bit的字节转换为四个6Bit的字节（38=46=24），然后把6Bit再添两位高位0，组成四个8Bit的字节，也就是说，转换后的字符串理论上将要比原来的长1/3。转换前aaaaaabbccccddddeeffffff转换后00aaaaaa00bbcccc00ddddee00ffffff
转换后，我们用一个码表来得到我们想要的字符串（也就是最终的Base64编码），这个表是这样的：（摘自RFC2045）Table1:TheBase64AlphabetValueEncodingValueEncodingValueEncodingValueEncoding0A17R34i51z1B18S35j5202C19T36k5313D20U37l5424E21V38m5535F22W39n5646G23X40o5757H24 Y41p5868I25Z42q5979J26a43r60810K27b44s61911L28c45t62+12M29d46u63/13N30e47v14O31f48w(pad)=15P32g49x16Q33h50y
填充符=。当需要编码的字符不是3的倍数，就会有余数1或2。这个时候就需要填充2位或1位来补齐，使转换后是4个字节，最多填充两个‘＝’如：字符串“张”11010101HEX:D511000101HEX:C5
001101010001110000010100十进制53十进制34十进制20pad字符’1’字符’i’字符’U’字符’=’"张"转换成Base64就是"1iU="，"张3"转换成Base64的结果是"1iU3"。
内容不同
本文档总体描述OMA-DM安全需求，并对传输层安全和应用层安全等进行描述。同时，也对完整性、机密性和健全的安全机制
建议翻译
OMADM协议基于SyncML协议，其旨在于允许对支持OMADM协议的设备进行远程管理。由于现阶段及未来需要管理的数据非常庞大，管理时，有必要对这些数据的重要性做一些考虑。在很多情况下，设备所操作的（或者传输的）数据是很重要的。某些情况下是机密数据，应该对数据的机密性做某种程度的保护。由于恶意或偶然的数据破坏可导致损失或影响后续执行效果，其他情况下，必须保证所传递数据的完整性。因此，实体（设备和设备管理服务器）之间的相互鉴权就显得很重要。
Bootstrap的安全机制
1.2版本把这部分内容从DMBOOT中移到Security来了。
要去掉
|
|
