已解决问题
看了很长时间的LTE加密，发现一个问题  (进入论坛模式)
提问者：630053570   |  提问时间：2011-12-15 21:18
UE在进行attach request时，向MME发送的UE security capability竟然支持空的加密和完整性保护算法，这是不是意味着UE可以不支持加密和完整性保护？如果不是这样，那为什么LTE标准会这样考虑，为什么不强制执行加密算法？
关闭所有答案回应     最佳答案
我的理解，其中有一个原因是，最早的版本还不支持有效的算法，只支持空算法。即先搭一个security的框架，在随后的版本中再支持有效的security算法。目前的实际测试中都不再使用空算法了。至于为什么还保留空算法，或许有别的目的。
 |  回应该答案 (0)  |  回答时间：2011-12-16 08:33
其他答案 ( 6 条 )
在某些国家，ZF会要求运营商不得加密，以方便强力部门进行监听、监控

顺便说一句，咱们天朝的GSM就没有加密
回应该答案 (0)  |  回答者：peterqiuy   (助理工程师一级)  |  2011-12-16 08:47
NAS的安全性是可选的，但是AS层是必选的，所以没问题
 |  回应该答案 (0)  |  回答者：固定无线接入   |  2011-12-16 16:34
空加密算法好像是在attach for emergency service的情况下才用的，当采用空加密算法时，也认为是加密的，空加密！=不加密，不知道理解的对不对
 |  回应该答案 (0)  |  回答者：kungfool   |  2011-12-17 23:34


这个想法比较有意思。不过我一直认为空加密就是不加密。求证！
 |  回应该答案 (0)  |  回答者：DR_KOG_POM   |  2011-12-20 08:48

正解！
2/3G现网中确实少见NAS层加密。LTE下NAS层加密倒是见过，但是一般试验局都是关掉省得不好troubleshooting
空口上数据相对容易获得，RRC加密必选；s1传输的NAS层在IP上承载，一般由运营商掌控，相对来说还算安全，不加密NAS也说得过去。不一定只针对emergency call，普通call不加密NAS也是正常的。
LTE下加密/完整性架构固定，同意空加密=不加密的说法。说白了就是一个字段没置位而已。
 |  回应该答案 (0)  |  回答者：hycl5410   |  2011-12-20 11:09
Security header type (octet 1)

8 7 6 5
0 0 0 0 Plain NAS message, not security protected

Security protected NAS message:
0 0 0 1 Integrity protected
0 0 1 0 Integrity protected and ciphered
0 0 1 1 Integrity protected with new EPS security context (NOTE 1)
0 1 0 0 Integrity protected and ciphered with new EPS security context (NOTE 2)

Non-standard L3 message:
1 1 0 0 Security header for the SERVICE REQUEST message

1 1 0 1 These values are not used in this version of the protocol.
to If received they shall be interpreted as ‘1100’. (NOTE 3)
1 1 1 1

All other values are reserved.

NOTE 1: This codepoint may be used only for a SECURITY MODE COMMAND message.
NOTE 2: This codepoint may be used only for a SECURITY MODE COMPLETE message.
NOTE 3: When bits 7 and 8 are set to '11', bits 5 and 6 can be used for future extensions of the SERVICE REQUEST message.
 |  回应该答案 (0)  |  回答者：hycl5410   |  2011-12-20 11:51