2024年终回顾

眨眼一瞬间,2024就此结束。今年发生了不少事,很大可能影响到后面几十年。

关键词1:制裁

实实在在的检验了一把美帝在金融领域的霸权。答案是确实威力十足,全球大公司的合规无处不在。虽然理论上只是金融机构受影响,但是考虑到连带效应,科技公司同样受影响。

互联网建墙,阻碍了信息流动,不过也给国内的企业留下了发育空间。信创项目,在我心目中也从以前纯纯骗补助项目,变成了五五开。供应链的国产化,更是势在必行。

我这种全球化的绝对拥簇,也在现实的教育下开始转向。所谓人教人不会,事教人一次就会。

PS. 不知道我国的制裁力度如何,听说效果不错。

关键词2:和解

与自己和解。世上很多事顺势而为,得之我幸,失之我命。很多事情的种子,其实在很多年前都已经种下。以前的选择决定了现状;现在的决策也能左右未来。

关键词3:实力

现代社会一个重要特点,就是单打独斗不可能成事。可是依附于组织,又会尽量的削弱个人的影响。怎么样才能有效的结合公司的实力和自己的实力,来达成组织目标,确实很考验管理技巧。

2021年,老美提出“from a position of strength”跟我们谈话,被顶了回去,说我们不吃这一套。结果今年年底不知道咋回事,最后几天集中发布各种先进武器。现在还有点好奇,到底是谁来从实力地位出发了。

“百年未有之大变局”,以前看是大话空话,看来还是我肤浅了啊。

英飞凌EUCLEAK

继上次TPM ROCA漏洞(CVE-2017-15361)后,英飞凌再次爆出漏洞。

本次漏洞由NinjaLab发现,论文名称为“EUCLEAK(https://ninjalab.io/wp-content/uploads/2024/09/20240903_eucleak.pdf)”,核心是通过侧信道攻击,能够取得英飞凌(Infineon)SLE78系列的ECDSA私钥。

研究者在网上买了飞天诚信的A22 IC卡,自己写了Javacard应用,下载到卡上进行实验和验证。在验证了自己的测试方案后,再拿同系列(SLE78)的Yubico产品进行验证,也成功获得了对应ECDSA私钥。

ECDSA在实践中,是用于签名。而私钥就是用来证明“你就是你”的核心数据。从这里就能看出,此次算法被攻破的严重性。

相比上次的ROCA漏洞,这次漏洞对智能卡界的影响更大

ROCA漏洞,导致的问题是在英飞凌芯片上用快速算法(Fast Prime)产生RSA公私钥对时,能够通过公钥反推出私钥。问题很大很严重,但是主要受影响的领域是在TPM,英飞凌或者NXP这些芯片商直接对接PC厂商。好在可以软件层面解决,所以上次主要的修复方式是笔记本厂商发布新的TPM固件。

另外根据事后爱沙尼亚发布的报告(Roca-vulnerability-and-eID-lessons-learned-2018.pdf (ria.ee)),一共有80万张数字身份卡受影响,不过好在他们可以远程升级进行修复;斯洛文尼亚召回了6万ID卡,西班牙召回1700万(存疑)。这些我怀疑不是ID卡本身的问题,而是服务器/CA端在给每张ID卡签署数字证书的时候,使用了受影响的芯片和算法,导致这些证书全部受影响。所以这里爱沙尼亚所谓的修复,也可能是重新签发和下载证书到卡上。

而这一次漏洞,受影响领域主要是在调用此加密库的产品本身。也就是说,如果产品需要调用此算法(ECC),那这个最终产品就会受到影响。而一般来讲,在发卡之后,是不会再留有通道来更新固件,也就是说,基本可以认为市面上所有采用此芯片的产品都有潜在风险,且无法修复。

在报告中,研究者通过查询英飞凌官网和CC网站的公开信息,定位了数款芯片,从制程来分,90nm有11款,65nm有3款,40nm有4款,以及28nm有1款。对于这个分类,做为业内人士,不能多说。

最终的最终,关于如何防护

目前来看,要成功实现攻击,需要满足如下条件

  1. 能够物理接触到产品,有的产品还需要特定条件才能使用
  2. 专业设备获取侧信道数据
  3. 专业知识进行数据分析和处理

所以看起来还算有门槛,不是那么容易出问题。而且和我们国家的普通人没关系,毕竟现在国内基本没有用它家相关芯片的。

目前我能想到的重灾区会是币圈和ID相关的灰产,有足够的动力来做这个事情。eSIM倒还好,实际使用场合的电磁环境比较复杂,集成度又特别高,没那么容易无感进行侧信道攻击。

真要防护,确保不脱离控制,尽早更换设备就好。什么法拉第电笼就没必要了。没这么小型的设备。

 

逆行人生

  • 第一条略
  • 不婚不育不买房
  • 听说美团有赞助这部电影?如果是的话,公关总监应该被裁掉
  • 但是徐峥还是收着,不敢再往深了拍。“算法中的外卖人生”拍出来深度是够了,但不谈资本层面的泥头车居合,光是受众就很奇怪。反正这个题材想来想去就不适合商业片
  • 既不敢拍系统性的问题,可也不敢拍外卖员的现实问题。逆行、闯红灯、甩尾漂移都快出来了,拍这么帅是想干啥?
  • 电影里面外卖员个个倒霉催的。其实我知道有不少人是宁可跑外卖也不进厂
  • 推荐大家再看看大刘的《赡养人类》。“终产者”这个概念当年震得我头皮发麻

巴黎奥运开幕式

08北京奥运会后,跟着是伦敦、里约和东京。今年来到了巴黎。

可能是热情耗尽,也可能是经济下行,大家漠不关心。反正周围似乎没听到人讨论奥运会的事情。我也同样,被超强“东京8分钟”拉爆期望,结果来了个史上最阴间的东京奥运会开幕式后,似乎也不再关心奥运会。这次巴黎奥运会,还是前几天看人吵带不带空调过去,才意识到它的到来。

由于时差关系,本次开幕式在周五晚上,所以是第二天早上起来看了一会儿重播。有点吃惊,居然随随便便搞了个露天开幕式,还下着不小的雨,看现场估计会被尬死。还好现在是电视时代,可以利用镜头艺术进行加工。

不得不说,老欧洲的遗产实在是太丰富,它们塑造了现代世界,自然在这方面得到了各种无形的回报。跟着蒙面火炬手穿梭在巴黎城中,仿佛重看了一遍近代史。巴黎圣母院,法国大革命,自由引导人民,卡门,蒙娜丽莎,断头皇后,中间穿插一段搞懵逼全世界老保的三人行,最后的晚餐COSPLAY以及蓝精灵变装秀,后面又接上小黄人致敬海底两万里,最后一个黑人女孩高唱马赛曲。这么多IP接踵而至,不需要特别的介绍,我自己都脑补出来。

话说回来,我发现中国人真的很宽容。虽然我们不谈政治正确,但是基本上对这些乱七八糟的LGBTxyz也就处于一个“只要你不干扰我,不影响我家人,那你自己随便玩,我不支持不反对”态度。除了最后小蓝人太丑(丑就是不对,颜值即是正义),其他批判声还算温和。但是这次Last Supper Cosplay真的是把好多老外搞破防,我看推上简直翻天覆地。可能还是触及到了这些保守基督徒的G点了吧。还有些不可提的也出来指责,因为耶稣也是他们的先知之一。

卢德运动与萝卜快跑

1. 萝卜快跑

无人驾驶这个概念,已经讲了很多年。各种政策以及试点也出台了不少,但是一直不在公众目光中显山露水。即使我这种关注科技新闻的,也以为重点还是在个人乘用车上。天天讲AI无法替代司机坐牢,这个法律风险不排除,主机厂永远不敢把它的L2.99999改为L3。

没想到,突然之间,这个概念被武汉职业司机的抗议给顶上了热点。

百度旗下的“萝卜快跑”,5月开始在武汉投了1000辆无人驾驶出租车。而它们6月份就产生了60万个订单。不要问,问就是便宜,10公里才4~16块钱,现在的出租车和网约车拿头去跟人拼。

其实,我一直以为这个事情会首先发生在货运卡车等物流企业上。如果优先考虑高速场景,可以做到

  • 封闭空间
  • 路况简单
  • 固定起始点

没想到,突然间居然全国全面开花。截止到今天(2024.07.11),全国已经有20个试点城市。如果不考虑社会就业冲击和立法规范,其实已经技术性可用。

新能源+AI,简直是无人产业的神兵利器。一路前行,无往不利。

2. 卢德运动

有个笑话,中年失业有三宝:快递,外卖,网约车。更好笑(带泪)的是,这三个目前看来都是无人驾驶的重点替代对象。

京东顺丰已经开始有无人快递车上路。以后看起来,所有标准物流环节都可能被无人化。接单、分拣、仓储、物流、派送,从中心仓到终端,都没有任何必须人力参与的部分。

而很多年以前,国内的酒店都已经推广了机器人。外卖员只需要把快递放到机器人里,输入房号,后续过程就交由机器人自动完成。在前几天,还看到了美团的无人机送外卖的视频。以后再打通低空经济产业链,完全可以考虑把低空区域划给自动驾驶物流。

按照维基百科的定义,技术性失业(英语:Technological Unemployment),指因技术进步,达成相同产能的劳动力需求减少,所引发的失业现象,例如在耕作农业机械发明并采用后,生产相同数量的农作物,所需的农民人数减少,而减少的农民能找到其他的工作前, 这些农民就会因为农业技术的进步而失业。

最出名的技术性失业,其实是每个中国学生都学过的“卢德运动”。它发生在英国工业革命时期,因为自动织机出现,效率极大提高的同时,对人手的需求反而在飞速下降。失业的工人没有其他的技能,选择破坏机器,来拯救自己的生计。

最靠近的一次,我认为其实是上世纪的大下岗。下岗潮有各种各样的因素,但是其本质就是中国国门开放,海外先进生产和管理技术的导入,直接冲击了原有的老工业基地。原有的工人也好,管理层也好,不管之前多有能力,在有限的机会下,大规模失业是无可避免的。

前段时间跟英国的客户聊天,就聊到现在技术进步所带来的就业风险。他很乐观,认为技术永远会进步,人们从繁重的劳动中解放出来,才能开创更广阔的领域,创造更大的价值,并产生更多的就业机会。

可是在转型过程中,必然会有技能固化的一批人,他们的知识结构和学习能力,导致了没办法,也没有机会转型。如果再叠加上持续过长时间的技术转型,旧的机会消失,新的机会还没有创造出来,可能会有一两代人都深陷其中。

在以前,转型的代价,其实就是这批人给承担了。当年的下岗潮有多惨烈,相信现在还是有人记得的。在即将来临的大变革时代,要怎么做,才会让这批人,不会成为技术进步的代价,这是一个需要系统性研究的课题。

 

APN 配置略解

0. 什么是APN?

APN, 是Access Point Name的缩写,即“接入点名称”。它决定了终端通过什么接入方式来访问网络。

在5G中,改称为DNN(Data Network Name,数据网络名称),但是它们的作用和定义还是一样的。

在独立组网部署(SNPN)中,把OI的格式固定为"nid<NID>.mnc<MNC>.mcc<MCC>.gprs"

1. APN的构成

按照3GPP TS 23.003 $9,定义了APN由两部分构成

  • APN-NI (Network Identity):必选。它定义 GGSN/PGW 连接到哪个外部网络。在后面例子中,apn里面其实写的都是APN NI。
  • APN-OI (Operator Identity):可选。它定义 GGSN/PGW 位于哪个 PLMN GPRS/EPS 主干网中

一个APN-FQDN可以表示为internet.apn.epc.mnc015.mcc234.3gppnetwork.org,其中internet为APN NI,剩下部分则是派生出来的APN OI。

1.1 APN-NI

APN NI由运营商自行定义,只是限定了某些固定搭配不能使用。

终端在“附着”请求流程中,会上报终端中的APN-NI。MME结合终端IMSI,构造出APN-FQDN,送至移动网内DNS服务器进行解析,获得PGW网关的IP地址。从而决定了终端采用哪种接入方式来访问网络。

1.2 APN-OI

对于每个运营商,都有一个默认的 APN 运营商标识符(即域名)。此默认 APN 运营商标识符从 IMSI 派生而来 “mnc<MNC>.mcc<MCC>.gprs”。这个默认APN-OI用于本地路由间的情况。

在漫游情况下,如果要选择来自 VPLMN 的GGSN/PGW,则 UE 的 APN-OI由服务网络 PLMN ID 构成。

2 APN参数

在下述例子中,我们能看到还有很多参数需要配置。但是找了很久没有找到在哪个规范里面有定义,很可能其实这些参数是移动通信中的标准参数,只是我接触这部分,所以不知道。最近似的一份材料来自GSMA TS.32。

对我来讲,我最关注的其实是mvno_type这个部分。

按照安卓和微软的源代码来看,手机通过三种方式来区分MVNO:

  • spn
  • imsi
  • gid

其中spn和imsi都是我们很熟悉的。GID的用途,其实跟TS 31.102中规定的不大一致。

下面例子均取自于android.googlesource.com

 <apn carrier="MVNO NL"
      carrier_id = "2149"
      mcc="204"
      mnc="03"
      apn="internet.mvno.mobi"
      user="mvno"
      password="mvno"
      authtype="1"
      type="default,ia,supl"
      mvno_match_data="20403"
      mvno_type="imsi"
  />

  <apn carrier="Truphone"
      carrier_id = "2143"
      mcc="204"
      mnc="04"
      apn="truphone.com"
      mmsc="http://mmsc.truphone.com:1981/mm1"
      type="default,ia,supl,mms,dun"
      mvno_type="gid"
      mvno_match_data="547275554B3030656E"
  />

  <apn carrier="CSpire international"
      carrier_id = "1836"
      mcc="204"
      mnc="04"
      apn="internet.cs4glte.com"
      server="*"
      user="Uniroam@inet.cs.com"
      password="cs3g"
      authtype ="3"
      mmsc="http://pix.cspire.com"
      mvno_type="spn"
      mvno_match_data="C Spire"
      type="default,ia,mms"
      protocol="IPV4V6"
  />