121、影像系统安全与隐私：加密传输与本地处理
去年夏天，我在调试某款车载环视系统时，遇到了一个让人后背发凉的bug。客户反馈说，在停车场用手机APP远程查看车辆周围画面时，偶尔会看到其他车辆的实时影像。排查了三天，最终定位到问题：我们用的RTSP流媒体服务器在公网传输时，视频流是明文的。某个路由器的组播转发配置错误，导致相邻车位的视频流串到了另一个用户的手机上。那一刻我意识到，影像系统的安全不是“加个密码”那么简单，它是一整套从传感器到显示端的信任链。
加密传输：别让你的摄像头变成别人的眼睛
影像数据的传输链路，往往是整个系统最脆弱的环节。我见过太多团队在ISP pipeline上花了大半年调优，最后用HTTP裸流传输——等于把精心调校的画面直接送给中间人。
传输层加密的“坑”与“解”
先说最基础的TLS/SSL。很多嵌入式工程师觉得在ARM Cortex-A上跑TLS太耗资源，于是自作聪明地只对关键帧加密。别这样写——攻击者只要拿到I帧，就能重建出可识别的画面。正确的做法是：对整个视频流做全加密，但可以分级处理。比如在车载场景，倒车影像的实时性要求极高，可以用轻量级的ChaCha20-Poly1305替代AES-256-GCM，前者在无硬件加速的平台上快3-5倍。
我在调试某款安防摄像头时踩过一个坑：固件里用了OpenSSL的默认配置，结果TLS握手阶段每次都要交换证书链，导致首帧延迟高达2秒。后来改成session复用+OCSP Stapling，首帧延迟降到300ms以内。这里有个经验：对于实时性要求高的影像
