장치 초기화 시, 시스템이 사용자 터미널로 인식되면 초기화 스크립트가 자동으로 41개의 SSH 공개키를 /root/.ssh/authorized_keys 파일에 기록함을 발견함, 포트 22도 항상 로컬 네트워크에 열려 있음, 41개나 되는 키를 쓰는 게 무슨 의미인지 궁금증 생김, 결국 '당신이 소유한' 사용자 터미널에 루트 접근 권한이 없는 사람이 누구인지 의문임
아마 당신일 것임, 더 진지하게 생각해보면, ISP가 제공하는 라우터에 원격 관리 시스템을 두는 것과 크게 다르지 않음, 만약 SpaceX가 사용자 터미널에 접근 권한이 없더라도, 위성이나 지상국에서 트래픽을 모니터링 할 수 있음
최근에 특수 정부 업무에 관련된 사람들과 추적 가능한 SSH 키가 있는지 확인할 만한 최적의 사람이 누구일지 궁금증 생김, 최근 좋은 유출도 있었음
41개 키가 단순히 41개 리전의 동일 서버 인스턴스일 수도 있음, Starlink는 글로벌 서비스이므로 딱히 걱정할 일은 아님, 41개 인스턴스가 하나의 키를 공유한다면 더 걱정할 것 같음
현재 다니는 회사에서는 개발자 SSH 키만 DEV나 QA 펌웨어에 배포함, 프로덕션 이미지는 서명 후 SSH가 아예 비활성화 되어 있음, 프로덕션에서 원격 진단을 위해 별도 소프트웨어를 사용하고, 이 역시 접근권한과 데브옵스의 승인 절차로 관리됨, 그래서 SpaceX의 선택이 의아함
나는 단일 사용자임에도 authorized_keys에 25개의 줄이 있음, 랩탑의 여러 yubikey, 아이패드와 아이폰의 키, 맥의 secure enclave 키 등이 섞여 있음, Starlink에 적어도 1-2명의 시스템 관리자가 더 있을 거라 상상함, 100개 공개키도 그리 어색하지 않은 숫자임
오히려 이게 생각보다 평범하고 보안상 좋은 선택일 수 있음, 수백만 단말기들이 모두 똑같은 키나 소수의 키를 쓰는 것보다는, 시리얼 넘버나 생산시기에 따라 분리된 여러 키를 사용하는 게 나음, 프라이빗 키는 소수 단말기 관리용으로만 사용되고, 키 관리도 분할될 수 있음
이 터미널이 현지 네트워크에 인터넷 연결도 같이 될 때만 외부에서 key로 접근이 가능할 것이라 추측함, SSH 접속을 위해 위성망을 어떻게 거치는지도 궁금함, Starlink가 NAT 등 네트워크 구조를 어떻게 쓰는지도 궁금함
이전에 올라왔던 유사 주제로 Starlink 사용자 터미널 분해 글 링크 공유함
41개의 공개키를 공개해서 어떤 개발자가 사용하는지 알아본다면 재미있을 것으로 생각함
Starlink 관련 블로그 포스트 아카이브 링크 공유
저자에게 제목의 오타("ternimal")를 수정해 줄 것을 요청함
이런 현상을 keming(글자 간격 불균형) 이슈의 고전적 사례임을 재치있게 언급함
모든 패킷이 유저스페이스에서 처리된다는 점이 놀랍게 느껴짐, 1Gbps 트래픽(100바이트 UDP 기준)이면 초당 백만 패킷임, 1GHz CPU는 패킷당 1000사이클만 사용 가능함, 이론상 가능하지만 쉽지 않음, 엔지니어가 어셈블리 직코딩에 온갖 트릭을 총동원해야 할 수준임
논문에 따르면, 네트워크 스택 구조가 DPDK와 유사한 구조로 보이고, 패킷의 커널 바이패스 처리가 핵심임, 실제로는 처음 패킷만 소프트웨어가 처리하고, 세션 성립 이후에는 하드웨어로 넘길 수 있음, 일부 패턴은 계속 소프트웨어에서 처리할 수도 있음, 예전 인텔 Puma 계열 케이블 모뎀 라우터에서도 이와 유사한 방식을 경험했음
DPDK 스타일 포워딩의 경우 버퍼 카피가 줄어들어 오히려 더 빠를 수 있음, Starlink는 25-200Mbps 수준이고, 평균 패킷 크기가 7-8배 크다는 점에서 초당 약 3만6천 패킷 수준임, 1GHz CPU에선 감당할 만한 양임
커널에서 패킷 처리하는 것보다 userspace에서 덜 효율적일 이유가 무엇인지 의문임, 하드웨어 큐를 유저스페이스로 매핑하면 커널-유저스페이스 구분이 중요하지 않아짐
Starlink의 경우, 100바이트 UDP 패킷보다는 일반 1500바이트 MTU를 사용함
userspace에서 패킷을 처리하면 불필요한 메모리 카피가 줄어들어 훨씬 빨라짐
이런 장비의 리버스 엔지니어링을 어떻게 시작해야 할지 궁금증을 표현함, 리버스 엔지니어링은 어렵고, 예시 대부분 오래된 혹은 비싸서 하기 어려운 경우가 많음
우선 하드웨어 엔지니어링을 먼저 익혀야 함, 부품의 용도나 특성을 모르면 리버스 엔지니어링 자체가 어려움
첫째는 제품을 직접 사서 분해해야 함, 둘째는 분해 후 뚫을 방법을 생각해야 함, 셋째는 실제로 시도함, 넷째는 망가졌다는 사실에 좌절함, 보통 UART 포트로 진입하는데, Starlink에는 없는 듯 하니 eMMC 메모리 칩을 떼서 분석한 사례임
QEMU 기반 에뮬레이션 환경에서 외부 장치(GPS 등)에 연결되는 펌웨어 에뮬레이션 참고 자료나 레디 솔루션이 있는지 질문함
안드로이드 QEMU 포크에서 OpenGL, GPS, GSM, 센서 등 다양한 하드웨어와 GUI 인터페이스를 에뮬레이션 한다는 점을 사례로 소개함
펌웨어를 리버스 엔지니어링으로부터 보호하는 방법을 배우고 싶음, SpaceX가 사용하는 기술에 대한 입문 자료가 있는지 궁금함
1단계는 펌웨어 암호화와 같은 조치임, SpaceX도 딱히 선제적으로 대응하지는 않고, 꾸준히 발견되면 그때그때 패치하는 듯 함, 예전엔 디버그 핀도 있었음
활용해 본 수많은 제품이 펌웨어 쪽 완성도가 낮은 경우가 많았음, 보안 목적 외에는 굳이 잠그지 말고 모두에게 도움 되는 데에 자원을 쓰길 부탁함, 파워유저는 기기를 직접 수정할 수 있으면 오히려 장점임, 정말 심각한 침해 위험이 없다면, 굳이 쓸데없이 시간 쓰지 않았으면 함, 각종 기기를 필요에 맞게 해킹해야만 하는 현실이 아쉽고 때론 우울함
최소한 루트 파일 시스템을 암호화하면서,도난이나 추출이 어려운 실제 보안 칩의 시크릿 정보를 활용하는 게 기본임, 한층 더 보안 수위를 높이고 싶으면 ARM TrustZone을 이용하여 부트로더, 복호화, 이미지 서명 등 민감한 작업을 격리할 수 있음, 파일시스템을 쉽게 덤프할 수 있다는 것 자체가 SpaceX가 실질적 보호 장치를 사용하지 않는다는 뜻임, 부트로더만 보호되고 그 외엔 노출되어 있음
이 장비가 혹시 로켓과 같은 코드베이스를 쓰는지, 신기하다고 느낌을 표현함
오히려 더 멋지게 느낀 부분은 위성과 코드베이스를 공유하거나, 위성 시뮬레이터 정도일 것 같음, 각종 텔레메트리를 보내야 하기 때문임